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
hi i need some help in my fyp which is to develop a fpga based encryption module for voice comunitcation any 1 cn help me out in itArticle: 134901
On 5 Sep, 16:01, amig...@gmail.com wrote: > hi i need some help in my fyp which is > to develop a fpga based encryption module for voice comunitcation > any 1 cn help me out in it What certificate will I get? http://www.gsm-security.net/faq/gsm-encryption-algorithm-a5-cipher.shtmlArticle: 134902
Kevin, Let me add my 2 cents... When the count1 vs count2 example was submitted, I suspect the author wanted to demonstrate how a user could think he would be implementing a "safe" counter (i.e. that immediately goes back to zero when an illegal value is detected) by using ">" instead of "==". Clearly, this is flawed thinking as synthesis tools are smarter than the autor thought. With either code, decent synthesis tools extract a counter that increments from 0 to 133, and loops back. Note that I thus disagree with the statement that using ">" is different/better than using "==" for these counters. Moreover, the third implementation you submitted again describes the exact same counter (the type used to described the counter makes no difference). Consequently, the area/ performance results really ought to be *identical* for all 3 implementations - Yet you report slight variations in area. As you reported LE numbers, the difference could come from packing LUTs with FFs. Would you mind sharing the number of LUTs and FFs with us? It is also interesting to note that implementing the ">" operator does take more resources than the "==" operator. The first one is essentially a subtractor (which only looks at the sign of the result) while the latter is a wide NXOR/AND gate. Now, modern FPGAs all have built-in carry chains, making adding/subtracting fast and cheap. Yet, a 16-bit wide subtractor should consume 16 LUT4s (and 16 Carry Muxes) while a 16-bit wide comparator should consume 11 LUT4s. For 8-bit wide, the subtractor should consume 8 LUT4s, while the comparator should consume 5 LUT4s. Now, this difference is irrelevant in the counter discussion, as the synthesis tool will use the same comparison method, regardless of the original coding style. Truly timing-driven synthesis tools (like Synplify) will even choose the comparaison operator based on timing requirements. For a large incrementer, I would expect the subtraction to yield faster results at the expense of more resources. Finally, I noticed something worth investigating in your data: the 8- bit/135 implementation takes ~11 LEs, while the 24-bit/135 implementation takes ~32 LEs. This seems wrong. Indeed, with a max value of 134, the synthesis tool should trim down the 24-bit counter to just 8 bits. Thus, these two implementations ought to produce identical results. Again, this could come from reporting LEs, where IO atoms could be included. Getting the LUT and FF count should clear this up. - gael PS: the advanced readers might wonder how they can force the operator of their choice in the above examples. The trick consists in having an explicit wire/signal that performs the comparison (> or ==) and then to apply an attribute that disables optimizations (syn_keep for Synplify, dont_touch for Precision, KEEP for XST, etc). From rgaddi@technologyhighland.com Fri Sep 05 10:55:43 2008 Path: flpi141.ffdc.sbc.com!flpi088.ffdc.sbc.com!prodigy.com!flpi089.ffdc.sbc.com!prodigy.net!bigfeed.bellsouth.net!bigfeed2.bellsouth.net!news.bellsouth.net!border2.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.lmi.net!news.lmi.net.POSTED!not-for-mail NNTP-Posting-Date: Fri, 05 Sep 2008 12:55:41 -0500 Date: Fri, 5 Sep 2008 10:55:43 -0700 From: Rob Gaddi <rgaddi@technologyhighland.com> Newsgroups: comp.arch.fpga Subject: Re: need sme help on data encryption based on fpga Message-Id: <20080905105543.20b7eaae.rgaddi@technologyhighland.com> References: <7c4b7c73-ba27-444b-a159-66863047d421@f36g2000hsa.googlegroups.com> Organization: Highland Technology, Inc. X-Newsreader: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lines: 18 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 66.117.134.49 X-Trace: sv3-GzqVW9z/aoRl0JxMZdnUhbC9pR8DDkEXVfTGMtu/11DaiEBs0zov/WVoWD1CYYqb1v5lokk7sDssLE+!U3g+58ug8/9RjuXJMkDeewcceRiQeT40bWaudVehNaIi4GakFeqWV7qUDGOq9w1N1qXIuVcqla1+!r9kPF8kFpko7KJ0WIDQ= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.39 Bytes: 2146 X-Original-Bytes: 2082 Xref: prodigy.net comp.arch.fpga:147709 X-Received-Date: Fri, 05 Sep 2008 13:53:33 EDT (flpi141.ffdc.sbc.com) On Fri, 5 Sep 2008 08:01:07 -0700 (PDT) amigo65@gmail.com wrote: > hi i need some help in my fyp which is > to develop a fpga based encryption module for voice comunitcation > any 1 cn help me out in it Certainly, observe: ======================================================= Hi. I need some help in my final year project, which is to develop an FPGA-based encryption module for voice communication. I would appreciate any help that anyone can offer me. ======================================================= One provides the slightest chance of your being treated like a professional. The other proudly proclaims that you while you need help badly enough to shout your request out into a field of total strangers, you can be bothered neither to a) capitalize, b) write out entire words, or c) spell check. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 134903
On Sep 5, 1:32=A0pm, Gael Paul <gael.p...@gmail.com> wrote: > Kevin, > > Let me add my 2 cents... > > When the count1 vs count2 example was submitted, I suspect the author > wanted to demonstrate how a user could think he would be implementing > a "safe" counter (i.e. that immediately goes back to zero when an > illegal value is detected) by using ">" instead of "=3D=3D". That may have been his point, I was simply disagreeing with his statement "You can see that both counters are identical, but if synthesized according to the RTL, count2 will have a lot more logic and will be slower, because the > with synthesize a subtractor". > Note that I thus > disagree with the statement that using ">" is different/better than > using "=3D=3D" for these counters. Kevin N said it ">" was worse not better. I said that ">" and "=3D" should result in "basically the exact same amount of logic resources and performance". So I'm not sure who or what statement you're disagreeing with. > Moreover, the third implementation you > submitted again describes the exact same counter (the type used to > described the counter makes no difference). I added the third implementation simply to show that using integers over a properly defined range does not result in any synthesis/ performace hits. Although not brought up in this thread, others have also claimed (incorrectly as well) in other postings that using integers caused more logic to be used. I just used it here to post yet another thing that people could use and see for themselves. > Consequently, the area/ > performance results really ought to be *identical* for all 3 > implementations You're making an incorrect assumption. The logic that is inferred is different for 'Cnt1' (the one using "=3D") than that of 'Cnt2' (the one using ">") so there is no reason to expect identical area/performace results. 'Cnt3' is identical in form to 'Cnt2' so I would expect them to produce identical results (and they did as far as I can tell). > - Yet you report slight variations in area. As you > reported LE numbers, the difference could come from packing LUTs with > FFs. Would you mind sharing the number of LUTs and FFs with us? > In Quartus land, what I reported as "logic elements" is equivalent to "LUTs" in other lands, it is the unit that implements logic. In all cases, the number of flip flops was equal to the the number of bits of output (i.e. either 8 or 24) and was the same for Cnt1, Cnt2 and Cnt3. > It is also interesting to note that implementing the ">" operator does > take more resources than the "=3D=3D" operator. The first one is > essentially a subtractor (which only looks at the sign of the result) > while the latter is a wide NXOR/AND gate. You're making assumptions again. The basic logic element in an FPGA is a lookup table, not a subtractor or NXOR/AND gates. Yes there are other hardware resources like carry chains, multipliers, etc. but you seem to be making the same mistake that Kevin N. did with his statement regarding resource usage on comparators...so I'll leave it at that. Also note that comparing a signal to a constant (as was being demonstrated) is quite a bit cheaper than comparing two signals. The values of the various bits of the constant basically disappear into the contents of the LUT and do not generally affect the number of LUTs. > > Finally, I noticed something worth investigating in your data: the 8- > bit/135 implementation takes ~11 LEs, while the 24-bit/135 > implementation takes ~32 LEs. This seems wrong. Indeed, with a max > value of 134, the synthesis tool should trim down the 24-bit counter > to just 8 bits. You should consider looking at what the code really says and ask yourself what happens if those nasty particles from outer space came along and magically changed the count value to 1,000,000 and what the next count value would be for the different implementations as it is spelled out in the source code (since that is the function being implemented by synthesis). With that understanding you'll see why it has to take more logic cells to implement the type of counter that I posted than it took for the 8 bit version. From there one can perhaps deduce the changes required to the source code to get it into a form that would synthesize to the same LUT usage (darn near) as the 8 bit version...but I'll leave that as an exercise for the interested. Kevin JenningsArticle: 134904
I'm trying to follow a guide on reviewing the equation by following these steps on the compilation report: Analysis & Synthesis -> Equations on the left side of the compilation report (the guide is on version 5). However, on version 8, I'm having a hard time finding this option. Does this option still exist? If it still does, how would I go about in terms of looking at the equation that is synthesized after compilation? Thanks in advance for the guidance.Article: 134905
On 4 Sep., 18:06, n...@puntnl.niks (Nico Coesel) wrote:
> Jochen <JFren...@harmanbecker.com> wrote:
> >We had an issue with a "ground bounce" (Spartan3 design) in the bank
> >containing the PCI-interface, which 'triggered' the asynchonous reset
> >of the PCI-core...
>
> >Do you use async resets ?
>
> Yes. The design uses async resets. But it doesn't seem to affect the
> PCI core. The problem is always in the part with the statemachines.
>
> --
> Programmeren in Almere?
> E-mail naar nico@nctdevpuntnl (punt=.)
well - let's have a look at
http://forums.xilinx.com/xlnx/blog/article?message.uid=12856
esp. chapter "Unreliable Sporadic Behaviour!"
/Jochen
P.S.
Ken really knows, what he is talking about !!!
Article: 134906I'm new to designing with altera, and by default the Quartus tool adds the following library declarations as part of my top level code template. library ieee; use ieee.std_logic_1164.all; library altera; use altera.altera_syn_attributes.all; I've compiled the altera libraries under modelsim using the supplied altera script. When I try to compile my top-level module in modelsim with the above declarations, I receive the following modelsim error. ** Error: (vcom-11) Could not find C:\Modeltech6.1f_de\fpga_libs\altera\vhdl\altera.altera_syn_attributes. ** Error: C:/projects/CDS/FDWU/FPGA/FDWU_Rev05/FDWU_top.vhd(18): (vcom-1195) Cannot find expanded name: 'altera.altera_syn_attributes'. ** Error: C:/projects/CDS/FDWU/FPGA/FDWU_Rev05/FDWU_top.vhd(18): Unknown record element "altera_syn_attributes". After a web search, I found the following suggestion to compile the altera_syn_attributes.vhd file into the altera library. http://www.alteraforum.com/forum/showthread.php?t=1709 Is there any reason I shouldn't compile the altera synthesis attributes into my modelsim altera library. As it turns out, I don't really need the 'use altera.altera_syn_attributes.all;' declaration, so I can just delete this declaration and fix my problem. But, I might be using altera attributes later so I want to go ahead and address the problem now. UrbArticle: 134907
"Gael Paul" <gael.paul@gmail.com> wrote in message news:30d93278-53bc-49ec-bf5f-> > Finally, I noticed something worth investigating in your data: the 8- > bit/135 implementation takes ~11 LEs, while the 24-bit/135 > implementation takes ~32 LEs. This seems wrong. Indeed, with a max > value of 134, the synthesis tool should trim down the 24-bit counter > to just 8 bits. Forgot to add, that the reason for posting the results for the 24 bit counter that counts in a restricted range that *could* be covered by 9 independent outputs (8 bits for the bits that are actually counting, 1 bit to zero out the other 16 outputs) is for those people who like to suggest that 'reachability analysis' will take care of them and those outputs that will always end up being 0 (under normal operating conditions) will be detected by the synthesizer which will then cause all the logic to be magically synthesized away and collapse down to generation of a single '0'. This example showed that such analysis, while it could have been done is not something that can always be counted on to be performed and that there will be a price to be paid for assumming that it will be done when in fact it is not. Feel free to post the synthesis tool used and the settings required to obtain the optimal synthesis output. KJArticle: 134908
On Sep 5, 9:56=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > On 5 sept, 15:53, rickman <gnu...@gmail.com> wrote: > > > On Sep 4, 5:05=A0pm, benn <benn...@hotmail.com> wrote: > > > > I'm looking into running uClinux on a Microblaze.. and I read that > > > Microblaze alone uses up about 900 logic cells... =A0not sure how man= y > > > gates that equates to, but anyone venture a guess if a Spartan II > > > (150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux? > > > If you know how many logic cells the Microblaze uses, why don't you > > just look at how many logic cells your FPGAs have??? =A0Gate count is a > > level removed from reality both in the design and in the chip. =A0So wh= y > > translate into the domain of a poor measurement? > > > Rick > > the gate count is sure ir relevant > but the MB LC count is also :) > > he needs to build the system and check it out > and change options to optimize > this can not be calculated from datasheets Of course. The only way to measure the LC count of a design is to build it. But you can't determine the size of a chip by the data sheets either. Xilinx routinely inflates the LC count in their data sheets. Of course, they claim that there is no physical entity called a Logic Cell (LC) so they can count them any way they choose! In reality, the rest of us consider an LC to be the pairing of a 4 input LUT and a FF. The vast majority of designs use more LUTs than FFs, so you can actually simplify this to the count of 4 input LUTs. RickArticle: 134909
Hi,
I've got a design that is in working order, albeit with a little more
diagnostic signals still in the source than I really want. I am using
the Xilinx Spartan 3E board, and I tend to use the on-board LEDs for
diagnostic purposes.
To that end, I have an entity which controls the PS/2 keyboard
connected to my home brew computer with the following declaration:
entity harp_keyboard_controller is
generic (clock_rate : natural); -- clock speed in Hz
port(clk : in std_logic;
--->>> kbd_leds : out std_logic_vector(7 downto 0);
kbd_clk : inout std_logic; -- keyboard clock signal
kbd_data : inout std_logic; -- keyboard data signal
interrupt : out boolean;
reset : in std_logic;
enable : in boolean;
write : in boolean;
address : in std_logic_vector(1 downto 0);
data_size : in ram_types.memory_size_t;
data_write : in std_logic_vector(7 downto 0);
data_read : out std_logic_vector(7 downto 0);
ready : out boolean);
end entity harp_keyboard_controller;
The 'kbd_leds' output signal was used for diagnostics, but is no
longer needed. Because I've been burned so many times by making large
changes to my source and then having the Xilinx tools generate
something that no longer functions properly, I took a stepwise
approach and first just removed the assignments to 'kbd_leds' in the
'harp_keyboard_controller' entity.
I rebuilt my project and it still worked.
At this point, 'kbd_leds' is not assigned inside
'harp_keyboard_controller', so then I tried to remove the signal from
the entity declaration, and the corresponding assignment in the
instantiation of the 'harp_keyboard_controller' entity.
I rebuilt my project and it fails to function properly.
I added both of the latter two removed items, rebuilt and the project
works.
I then removed the assignment to the 'kbd_leds' signal in my top-level
entity and rebuilt. The project still functions properly.
It's only when I remove the signal declaration from
'harp_keyboard_controller' that the project fails to function
properly.
I'm a software guy trying to do things with hardware, and while I've
learned a lot in the past 18 months, I am confounded by what appears
to be lack of quality in the Xilinx toolchain. It doesn't seem to me
that removing a completely unused signal should have an affect on the
resulting synthesized hardware.
Am I misunderstanding something, or is the Xilinx software really that
bad? In other words, should removing a completely unused signal cause
my design to be synthesized in a way so that it no longer works?
If that's the case, then can you explain to me how that can be?
thanks for any help or advice
--
Hot glass looks just like cold glass.
Article: 134910On 06 Sep 2008 17:04:58 -0700, thutt <thutt151@comcast.net> wrote: >Hi, > >I've got a design that is in working order, albeit with a little more >diagnostic signals still in the source than I really want. I am using >the Xilinx Spartan 3E board, and I tend to use the on-board LEDs for >diagnostic purposes. > >To that end, I have an entity which controls the PS/2 keyboard >connected to my home brew computer with the following declaration: > > entity harp_keyboard_controller is > generic (clock_rate : natural); -- clock speed in Hz > port(clk : in std_logic; > --->>> kbd_leds : out std_logic_vector(7 downto 0); > kbd_clk : inout std_logic; -- keyboard clock signal > kbd_data : inout std_logic; -- keyboard data signal > interrupt : out boolean; > reset : in std_logic; > enable : in boolean; > write : in boolean; > address : in std_logic_vector(1 downto 0); > data_size : in ram_types.memory_size_t; > data_write : in std_logic_vector(7 downto 0); > data_read : out std_logic_vector(7 downto 0); > ready : out boolean); > end entity harp_keyboard_controller; > >The 'kbd_leds' output signal was used for diagnostics, but is no >longer needed. [snip...snip...] >It's only when I remove the signal declaration from >'harp_keyboard_controller' that the project fails to function >properly. > >I'm a software guy trying to do things with hardware, #include <std_disclaimer> Me too, so maybe some of my own recent faux pas may be relevant. > and while I've >learned a lot in the past 18 months, I am confounded by what appears >to be lack of quality in the Xilinx toolchain. It doesn't seem to me >that removing a completely unused signal should have an affect on the >resulting synthesized hardware. This is somewhat of a swag but I note that kbd_leds isn't a signal, it's one of the black box's I/O ports and hooked up to the device pins (I guess "to its balls" is more correct, still ...). Are they still floorplanned in your user constraints file after removing them from the port definition? -- Rich Webb Norfolk, VAArticle: 134911
Rich Webb <bbew.ar@mapson.nozirev.ten> writes:
> On 06 Sep 2008 17:04:58 -0700, thutt <thutt151@comcast.net> wrote:
>
> >Hi,
> >
> >I've got a design that is in working order, albeit with a little more
> >diagnostic signals still in the source than I really want. I am using
> >the Xilinx Spartan 3E board, and I tend to use the on-board LEDs for
> >diagnostic purposes.
> >
> >To that end, I have an entity which controls the PS/2 keyboard
> >connected to my home brew computer with the following declaration:
> >
<snip>
>
> > and while I've
> >learned a lot in the past 18 months, I am confounded by what appears
> >to be lack of quality in the Xilinx toolchain. It doesn't seem to me
> >that removing a completely unused signal should have an affect on the
> >resulting synthesized hardware.
>
> This is somewhat of a swag but I note that kbd_leds isn't a signal,
> it's one of the black box's I/O ports and hooked up to the device
> pins (I guess "to its balls" is more correct, still ...). Are they
> still floorplanned in your user constraints file after removing them
> from the port definition?
The 'signal' at the top level isn't removed, it's still present and
quasi-used. It works like this:
-- S3E demo board has 4 slider switches & 8 LEDs.
-- I combine the switches and the LEDs to get 16 banks of 8 LEDs.
-- I have an array, 16 x 8 of std_logic which corresponds to the
LED values.
-- The bank of LEDs which is actively connected to the actual
on-board LEDs is selected by the slider switches.
The signal which was assigned to the output port of the
'harp_keyboard_controller' entity was one element of the 16-element
array. That element of the array was not used for anything else in
the design -- it's just for outputting the most recent byte received
from the attached PS2 keyboard.
At the point that I removed the assignment to the output port in the
top level design, the 'harp_keyboard_controller' did not use the port
at all -- it did not assign anything to it at all; it was completely
unused.
So, I just don't understand why removing a port that it unused can
make the design fail.
--
Hot glass looks just like cold glass.
Article: 134912A few of us have gotten together and started a hobby company that is building an FPGA board using the Xilinx Spartan 3E. We've done all the prototype and and are ready for out first build of 250 boards and we're ready to order the parts. So my question is, is there a cheaper way to buy 250 Spartan 3E FGPAs than paying the Digi-Key quantity 1 price? Doesn't anyone offer a quantity discount? thanks Bob SmithArticle: 134913
On Sep 6, 9:00=A0pm, Bob Smith <use...@linuxtoys.org> wrote: > A few of us have gotten together and started a hobby > company that is building an FPGA board using the Xilinx > Spartan 3E. =A0 We've done all the prototype and and are > ready for out first build of 250 boards and we're ready > to order the parts. > > So my question is, is there a cheaper way to buy 250 > Spartan 3E FGPAs than paying =A0the Digi-Key quantity 1 > price? =A0 Doesn't anyone offer a quantity discount? > > thanks > Bob Smith Once again we find that www.xilinx.com is a source of information for Xilinx parts. <http://www.xilinx.com/onlinestore/silicon/online_store_s3e.htm> Pick a vendor under the "BUY" column.Article: 134914
On Sep 6, 9:12=A0am, Paul Urbanus <urbpub...@hotmail.com> wrote: > > Is there any reason I shouldn't compile the altera synthesis attributes > into my modelsim altera library. > > Urb No. Just do it.Article: 134915
My apologies if my reply seemed abrasive. I just spent two hours - not- finding something on the Xilinx web site...Article: 134916
I just spent two hours looking for a package drawing. Still haven't found the one I'm looking for. I did find UG112. On page 117 it has a link for the package drawings. That link is dead. It does have a valid link to the Virtex4 package drawings. Not the ones I was looking for. I found 'mentor_pcb.pdf'. It says "Go to www.xilinx.com and click Documentation to find the user guide for your device." The user guides do NOT have package drawings. I found "AR #11956 - Packaging - Where can I find Xilinx packaging information and package drawings?" - the 1st answer links to (the useless) UG112. The 2nd (last) link is dead. I went to "Doc Type" -> "Package Specifications". Under "Design Files" all I can find is the "IPC-1752 Form". While a "Material Composition Declaration" is important, it is not what I need to make a PCB footprint. Just for fun, I went to a competitors web site. Three clicks from the home page (Literature -> Packaging -> Device Package) I found "DS- PKG-15.1", which has the footprint data for -all- of their packages in one convienent PDF.Article: 134917
On 7 sept, 09:06, LittleAlex <alex.lo...@email.com> wrote: > I just spent two hours looking for a package drawing. =A0Still haven't > found the one I'm looking for. > > I did find UG112. =A0On page 117 it has a link for the package > drawings. =A0That link is dead. =A0It does have a valid link to the > Virtex4 package drawings. =A0Not the ones I was looking for. > > I found 'mentor_pcb.pdf'. =A0It says "Go towww.xilinx.comand click > Documentation to find the user guide for your device." =A0The user > guides do NOT have package drawings. > > I found "AR #11956 - Packaging - Where can I find Xilinx packaging > information and package drawings?" - the 1st answer links to (the > useless) UG112. =A0The 2nd (last) link is dead. > > I went to "Doc Type" -> "Package Specifications". =A0Under "Design > Files" all I can find is the "IPC-1752 Form". =A0While a "Material > Composition Declaration" is important, it is not what I need to make a > PCB footprint. > > Just for fun, I went to a competitors web site. =A0Three clicks from the > home page (Literature -> Packaging -> Device Package) I found "DS- > PKG-15.1", which has the footprint data for -all- of their packages in > one convienent PDF. welcome the real life whenever i touch xilinx website/docs or tools i either trap a bug or something else frustrating within 30 minutes they are getting better, belive me, but their webmaster seems to be on permanent vaccation. AnttiArticle: 134918
On Sep 4, 2:05=A0pm, benn <benn...@hotmail.com> wrote: > I'm looking into running uClinux on a Microblaze.. and I read that > Microblaze alone uses up about 900 logic cells... =A0not sure how many > gates that equates to, but anyone venture a guess if a Spartan II > (150k gates) with 16MB of RAM, 4MB Flash is enough to run uClinux? I'd guess "no". MicroBlaze hasn't been supported in the Spartan-II since EDK-6.3.Article: 134919
On Sep 7, 12:00=A0am, Bob Smith <use...@linuxtoys.org> wrote: > A few of us have gotten together and started a hobby > company that is building an FPGA board using the Xilinx > Spartan 3E. =A0 We've done all the prototype and and are > ready for out first build of 250 boards and we're ready > to order the parts. > > So my question is, is there a cheaper way to buy 250 > Spartan 3E FGPAs than paying =A0the Digi-Key quantity 1 > price? =A0 Doesn't anyone offer a quantity discount? Not only can you pay a lot less than the Digikey price, you need to negotiate to get it as low as possible. You have the most leverage if you have not yet designed in the part. So no matter what stage your project is in, contact your local disti and tell them you want a quote on parts for a new design that will be going to production in a few months. Do not let them know that you are ready for production and the Xilinx part has already been picked. You will need to give them a program name and an estimated annual quantity. That quantity should be a minimum of 5000 per year; they don't/can't hold you to it. To be safe, tell them the volume will start slowly, but it will ramp over the next year or two. It will take about a week to get the quote and then you can turn around and put in the order. You can refer to the 250 piece purchase as a pilot production run. I don't feel at all guilty about over-estimating my quantities. It is the only way to get a decent price. I have had disti salesmen take my numbers and inflate them further! Vendors of other types of parts will publish prices for quantities up to at least 1000. But the FPGA vendors hold their cards to their chest and you "play" the game by their insistence. So I play the game... I have gotten quotes on a part and package only to find that they have released a new, smaller package. The quote on the smaller, lower pin count package is then not as low as the higher pin count package. This was not because the package was in demand or that it was more expensive. It was because the first quote got attention as a "new" customer and the second quote didn't. Also be aware that unless you find stock at a distributor, you may have to wait months for parts. Even if they indicate factory stock, this can take many weeks to get shipped out from an overseas warehouse and delivered in your country. I have had "factory stock" take 6 weeks before. Then on top of that, even if they are quoting stock when they take your order, it is subject to "prior sale" and the high volume customers get what they want... always! RickArticle: 134920
On 06 Sep 2008 20:12:16 -0700, thutt <thutt151@comcast.net> wrote: >The 'signal' at the top level isn't removed, it's still present and >quasi-used. It works like this: > > -- S3E demo board has 4 slider switches & 8 LEDs. > -- I combine the switches and the LEDs to get 16 banks of 8 LEDs. > -- I have an array, 16 x 8 of std_logic which corresponds to the > LED values. > -- The bank of LEDs which is actively connected to the actual > on-board LEDs is selected by the slider switches. > >The signal which was assigned to the output port of the >'harp_keyboard_controller' entity was one element of the 16-element >array. That element of the array was not used for anything else in >the design -- it's just for outputting the most recent byte received >from the attached PS2 keyboard. > >At the point that I removed the assignment to the output port in the >top level design, the 'harp_keyboard_controller' did not use the port >at all -- it did not assign anything to it at all; it was completely >unused. > >So, I just don't understand why removing a port that it unused can >make the design fail. I have one question and a suggestion. What exactly do you mean by "project ... fails to function properly" ? What parts of it break down? That may help to figure out what's going on. The suggestion is based on an assumption. If you left the switch selection still at the keyboard output, does it help to change it to another of the 16 possibilities? -- KalArticle: 134921
LittleAlex wrote: > I went to "Doc Type" -> "Package Specifications". Under "Design > Files" all I can find is the "IPC-1752 Form". While a "Material > Composition Declaration" is important, it is not what I need to make a > PCB footprint. It has been awhile but I found something on .... http://www.xilinx.com/support/documentation/package_specifications.htm While there are a huge number of links, the packages seem to be sorted from largest to smallest. hope this helps Bob SmithArticle: 134922
Hi FPGA specialist, we are would like to know if it is currently possible to implement high speed LVDS receiver or transmitter in FPGAs. Our next gerneration PCB board would have about 12 LVDS receiver (SN65LV1224B) , 6 LVDS transmitter (SN65LV1023A) and an FPGA onboard. Please note that the LV1224 and LV1023 transmit thair LVDS in a single differential line, there is no LVDS clock pair necessary. The clock speed would be 48Mhz which would lead to a LVDS bandwidth of 576Mbs (12bit transmitting). It would save us money and FPGA IOs if we could get the serialization and deserialization in the FPGA. I could find application notes about LVDS in a cyclone3, but I don't think that reception works without a clock pair. Is anybody out there which as experience with this kind of LVDS in a FPGA? We would be obliged for some practical hits... Curious about your answers, Wolfgang KoppArticle: 134923
thutt wrote: > Am I misunderstanding something, or is the Xilinx software really that > bad? In other words, should removing a completely unused signal cause > my design to be synthesized in a way so that it no longer works? > > If that's the case, then can you explain to me how that can be? What you describe very often happens when there are constraints missing, usually timing constraints. When certain paths are not constrained, they tools just lay them out so it's most convenient for them. In many cases and with slow clocks this is not a problem. Modern FPGAs are fast, and if it's a slow clock and a small FPGA you can basically go around the entire chip twice and not have any timing issues. If it's a faster clock, you eventually get to the point where a design sometimes works and sometimes not, depending on how the tools lay out everything. It might happen that between different synthesis runs some paths are layed out differently, in one case just short enough that you don't get any timing issues and in another case just too long. Things like that happen easily if you change the code. It doesn't have to be a major change, but every tiny change is enough to modify the starting conditions for all the algorithms the tools implement, and then it might happen that i.e. the placer decides it's better to place some register in the top left instead of the bottom right, and suddenly everything around it changes position as well. That's what timing constraints are for: the tools should check every path and make sure all paths are short enough so you don't get any timing issues. So I suggest you check if all the clocks in your design are properly constrained. The same problems you describe can occur not only if you don't constrain at all but also if you under-constrain, i.e. set the clock to 25 MHz when it's actually 40 MHz or something similar. Xilinx' Timing Analyzer can also help there, there's an option to display all unconstrained paths in your design. Ideally, there shouldn't be any. Plus, there shouldn't be any timing violations in the Xilinx report files, of course. HTH, SeanArticle: 134924
Just a short update: Yesterday I released a new version that supports for the first time the PPC440 in the Virtex5 FXT. A demo running out of the box on the ML507 board is also included. The GUI runs quite well on the PPC that is clocked at 300 MHz. The resolution in this demo is 1024x768. In case somebody is present at the FPL'08 in Heidelberg these days: My research group presents a demonstrator that is entirely controlled by Genode FX. The demonstrator shows an application-specific instruction-set processor (ASIP) for channel coding (convolutional and turbo coding) running on the ML507. To learn more about Genode FX visit: http://www.genode-labs.com/products/fpga-graphics To download Genode FX sourcecode and demo projects visit: https://sourceforge.net/projects/genode-fx/ Matthias
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