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
On May 28, 10:47=A0am, Hauke D <hau...@zero-g.net> wrote: > A while back, Andy Ross posted a Perl script that pulls together the > many steps required to program a Digilent Nexys2 board under Linux: > > http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/c7... > > I just wanted to let everyone know that this script, along with the > firmware it uses, is hosted at the "ixo-jtag" project on SourceForge: > > http://ixo-jtag.sourceforge.net/ Awesome! Thanks, PatArticle: 147876
On May 28, 7:05=A0pm, Gabor <ga...@alacron.com> wrote: > On May 28, 9:47=A0am, Sharath Raju <brshar...@gmail.com> wrote: > > > > > I am afraid I forgot to include the code in the previous email: > > > DBR : Core512 port map ( > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 -- Ram A > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ena =3D> ENA, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enb =3D> ENA, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wea =3D> WE, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 web =3D> WE, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssra =3D> SSR, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssrb =3D> SSR, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clka =3D> CLOCK, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clkb =3D> CLOCK, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addra =3D> addr_1, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addrb =3D> addr_2, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 douta =3D> DOUT(71 down= to 36), > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 doutb =3D> DOUT(35 down= to 0), > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dina =3D> DIN(71 downto= 36), > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dinb =3D> DIN(35 downto= 0) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ); > > > -- Address Declaration > > addr_1 <=3D '0' & ADDR(7 downto 0); > > addr_2 <=3D '1' & ADDR(7 downto 0); > > > The code isn't much. Essentially, I am trying to pretend to have a 256 > > locations X 72 bits deep memory, whereas the BLOCK RAM is physically a > > 512 locations X 36 bits wide. > > > On May 28, 6:31=A0pm, Sharath Raju <brshar...@gmail.com> wrote: > > > > Hello, > > > > We are working on a project which involves using BLOCK RAMs. Since we > > > were new to Block RAMs, I (my colleague actually) instantiated a BLOC= K > > > RAM in VHDL using Xilinx's Block RAM IP core. > > > > The question is regarding timing: > > > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device > > > specifies the best case (setup + hold) time to be less than 1 ns, and > > > the maximum frequency of operation to be 280 MHz. Worst case figures > > > are not specified. > > > > =A0However, we checked the static timing report and found the setup > > > times for the data, address and control signals to be approximately 4 > > > ns. > > > > Why is there such a substantial difference ? > > The static timing report includes clock to output delays > of the driver as well as routing delays in addition to > the actual Tsu of the RAM itself. =A0This should be broken > into individual parts and well described in the timing > report. =A0Generally speaking, you should always assume > that routing delays will constitute a significant > portion of your timing budget for any path. =A0According > to Xilinx, the tools target 60% / 40% as a goal for > logic delay / routing delay. > > HTH, > Gabor Thanks gabor .. shall check the static timing report in more detail for the routing and clock to out delays.Article: 147877
On May 28, 3:23=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > Rob Gaddi <rga...@technologyhighland.com> wrote: > > My problem with QFPs is that those long leads on 0.5mm pitch are perfec= t > > solder wicks. =A0Our BGA soldering yield is 100%, whereas we have to cl= ear > > at least one bridge on QFPs about half the time. > > I'd love a 49 ball, 1mm pitch part. =A0With 6/6 rules you could route o= ut > > all but the inner 9 balls on the top layer; with 5/5 you could route ou= t > > all but the center (which in a sensible world would be ground anyhow). > > That would put it at about 8mm on a side while still providing enough I= O > > pins to do something interesting. > > Some spare rows between the center supply and the IO pins on the outer ro= ws > could also make a two layer enabled BGA package. > > Otherwise the XC3S50A-VQ100 with a small SPI flash could could be what th= e > original poster asked for... Hi Uwe, I have seen the Xilinx parts and they don't do much for me. Compared to what I am using now, the 3S50 is less than half the size at only 1400 LUTs while the 3S200 is only slightly larger at 3600 LUTs vs 3000 LUTs. The 3S200 is not any cheaper and uses more board space with the SPI flash as well as costing more. I am trying to make the same board cheaper and have *no* extra space on the board. So to add an MCU, I need to reduce the size of the FPGA. I would love to ditch the FPGA and go 100% software, but there is one interface that makes that impossible I think. The app configuration data (not FPGA configuration) comes over a serial port that has timing requirements for read that you can't meet with software. So a small ram block has to be written and read in some sort of PLD. That is why I can't use most of the CPLDs on the market. Cypress has a configurable CPU out, but their analog is not too good and the digital is not very programmable. The Actel FPGA with a CPU is way too expensive at $40. Currently the CODEC used is $2 and the FPGA is under $10 in a TQ100 package (flash based so no external flash). I just can't seem to beat this combination either in price or board space. The only thing I can do is to put a CPU into the FPGA which is an option I have been considering for a while. I just would prefer to use a standard MCU which would give me a lot more memory than the 6 kB currently available, but they just don't make an FPGA which will fit this design. RickArticle: 147878
On May 28, 1:37=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > On 5/28/2010 10:17 AM, rickman wrote: > > > > > On May 28, 6:32 am, John_H<newsgr...@johnhandwork.com> =A0wrote: > >> On May 27, 2:05 pm, rickman<gnu...@gmail.com> =A0wrote: > > >>> How can a sync ram be used at all if an async reset is specified in > >>> the HDL? =A0There is no way to "add" an async reset to a sync memory. > > >>> Rick > > >> =A0From the original poster 2 messages before yours: "The reset logic = was > >> sequential, i.e. reset address 0, then reset address > >> 1, one per clock until the entire thing was done." =A0Nothing > >> asynchronous here. > > > That shouldn't prevent a memory from being used then. =A0That's just > > logic driving the RAM. =A0I would guess there was something about the > > code that couldn't be done with a ram. =A0Actually, looking at his code= , > > I don't see where he is writing to the ram ram_dat. =A0fir_cascade is > > written, but I don't see where it is initialized. =A0I don't get his > > code. =A0It looks more like software than hardware. =A0I'm used to > > debugging hardware... > > > Rick > > ram_dat gets written in the IIR state and the RESET state. > --- > =A0 =A0 =A0if msd_rdy then > > =A0 =A0 =A0 =A0 =A0 =A0-- Update the stored data and advance the > =A0 =A0 =A0 =A0 =A0 =A0-- write pointer. =A0Also decrement the FIR index,= which > =A0 =A0 =A0 =A0 =A0 =A0-- we're just using to count IIR stages at this po= int. > > =A0 =A0 =A0 =A0 =A0 =A0ram_dat(TO_INTEGER(write_idx)) =A0<=3D y; > --- > =A0 =A0 =A0 =A0when RESET =3D> > =A0 =A0 =A0 =A0 =A0-- Initialize the states for both filters > =A0 =A0 =A0 =A0 =A0ram_dat(TO_INTEGER(write_idx)) =A0<=3D (others =3D> '0= '); Not sure what is wrong, I can't find this code in your post. But I if this is your code, then yes, I guess it is being written. > Looking through the XST report, it was definitely generating ram_dat as > a RAM. =A0But it for some reason it was insisting that the reset > implementation happen on it's very own dedicated write port, which was > exploding the logic requirements 4-fold. > > Ultimately the answer was just to trust the Xilinx global reset on > powerup to zero out the RAMs and forgo the runtime reset. =A0Which will > work, it's just a little less elegant/portable. I was thinking about this the other day. Yes, the RAM is initialized when the bitstream is loaded, but that is different than the FFs being set/cleared on GSR. If you want the ram reinitialized, you have to reconfigure the part. BTW, I expect you know you can init the RAM to arbitrary values, right? But I guess anything other than zero in the data ram is not too useful. It can load default filter coeffs for you though. RickArticle: 147879
On Fri, 28 May 2010 10:37:28 -0700, Rob Gaddi
<rgaddi@technologyhighland.com> wrote:
>
>ram_dat gets written in the IIR state and the RESET state.
>---
> if msd_rdy then
>
> -- Update the stored data and advance the
> -- write pointer. Also decrement the FIR index, which
> -- we're just using to count IIR stages at this point.
>
> ram_dat(TO_INTEGER(write_idx)) <= y;
>---
> when RESET =>
> -- Initialize the states for both filters
> ram_dat(TO_INTEGER(write_idx)) <= (others => '0');
>--
>
>Looking through the XST report, it was definitely generating ram_dat as
>a RAM. But it for some reason it was insisting that the reset
>implementation happen on it's very own dedicated write port, which was
>exploding the logic requirements 4-fold.
>
>Ultimately the answer was just to trust the Xilinx global reset on
>powerup to zero out the RAMs and forgo the runtime reset. Which will
>work, it's just a little less elegant/portable.
Another answer would be to write
ram_dat(TO_INTEGER(write_idx)) <= y_zero;
in both states (trusting ... but verify!) synthesis to combine them;
but to mux either Y or 0 onto y_zero according to the state.
e.g.
process (...)
variable y_zero : signed_48;
variable wr_idx : integer;
begin
if rising_edge(clk) then
wr_idx := TO_INTEGER(write_idx); -- write the ugliness once!
y_zero := y; -- default value, eliminates latches!
case state is
when FIR =>
ram_dat(wr_idx) <= y_zero;
when RESET =>
y_zero := (others => '0');
ram_dat(wr_idx) <= y_zero;
...
Hopefully synthesis can't mess that up too badly!
- Brian
Article: 147880On May 28, 12:55=A0pm, "onkars" <onkars@n_o_s_p_a_m.n_o_s_p_a_m.winlab.rutgers.edu> wrote: > Hi, > > How can I estimate the resoures used by a core generated by CoRE GEn ----= I > guess the resource utilization report should give this right? > > What do the percentages in the resource utilization report of CoreGEN > indicate --- is it the percentage of total FPGA resource OR is it > percentage with respect to the total core size? > > Where can I get more details on reading/understanding the resource > utilization report? > > Also how can I find the speed performance of the core -- just an estimate > -- for the core in isolation is also OK. I'm pretty sure the data sheet for each core specifies the core's size and performance. -aArticle: 147881
You can't meet the SI requirements of modern sub-ns rise time silicon's I/O in 'easy to solder' packages. It's because of the loop area. BGAs "are harder to probe" made me laugh! I bet you still have a logic analyser! One way to prevent yourself becoming an extinct dinosaur is to splash the cash on some decent stimulation tools. Your competitors have. Syms.Article: 147882
"Symon" <symon_brewer@hotmail.com> wrote in message news:htpkq7$435$1@news.eternal-september.org... > You can't meet the SI requirements of modern sub-ns rise time silicon's > I/O in 'easy to solder' packages. It's because of the loop area. > > BGAs "are harder to probe" made me laugh! I bet you still have a logic > analyser! > > One way to prevent yourself becoming an extinct dinosaur is to splash the > cash on some decent stimulation tools. Your competitors have. > > Syms. Lighten up Syms ! For serious work with hardware I need a logic analyser and a scope !! (if you can suggest a "stimulation tool" substitute I'm listening). I'm totally with Rick on this one - TQFP easy to hand solder, easy to probe, check, modify etc. Most of my designs are one or two off, weirdo interfaces for production line test systems - the largest production run I've ever done with an FPGA was about 100 off. I can see the appeal of BGA for mass production but I'm convinced that TQFP is cheaper to prototype in low pin counts. A serious FPGA (>20K LUT) in 100 pin TQFP would be very nice. But I accept that the number I might buy wouldn't make the supplier very rich. Michael KellettArticle: 147883
Rob Gaddi <rgaddi@technologyhighland.com> wrote: >On 5/28/2010 10:05 AM, rickman wrote: >> I am looking at reducing the cost of a board while improving the >> performance and one way is to add a processor to offload the low >> bandwidth portions of an FPGA design and then reduce the capacity of >> the FPGA. Using an FPGA with 5 volt tolerant I/Os will let me remove >> a couple of quick switch parts as well. This has potential of saving >> a few bucks off the top and greatly improving the usable capacity of >> the device. However... there just don't seem to be *any* FPGAs that >> fit the bill. >> >> 5 volt tolerance (a potential bonus, but not required) >> small package/low pin count, not BGA, ~32 usable I/Os, 48 TQFP ideal >> 500 LUTs and 256 bits of memory >> Price<$5 >> >> Currently the entire design is in a Lattice XP device with 3k LUTs, >> but is 90% utilized with a recent capability upgrade. I can't even go >> with a larger FPGA without also going to a BGA package which drives >> the price up. I don't like BGAs because they take extra space for >> fanout of the signals and they are harder to probe than QFPs. I don't >> think any two of these three requirements can be found in the same >> part. Well, maybe CPLDs come in smaller packages at a low cost... >> >> I'm just surprised that there isn't more demand for FPGAs in low pin >> count packages. I guess I'm getting to be a dinosaur in my preference >> for QFPs. Still, I don't think you can even find a FPGA under $10 in >> a BGA package because the pin count is typically higher which drives >> the part cost up. >> >> Just some thoughts about my continued frustration in reaching design >> goals. >> >> Rick > >My problem with QFPs is that those long leads on 0.5mm pitch are perfect >solder wicks. Our BGA soldering yield is 100%, whereas we have to clear >at least one bridge on QFPs about half the time. Sounds more like a soldering process problem than a package problem. We use a lot of QFP packages for many different devices and we never see solder bridging problems. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 147884
On May 28, 3:47 pm, Hauke D <hau...@zero-g.net> wrote: > A while back, Andy Ross posted a Perl script that pulls together the > many steps required to program a Digilent Nexys2 board under Linux: > > http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/c7... > > I just wanted to let everyone know that this script, along with the > firmware it uses, is hosted at the "ixo-jtag" project on SourceForge: > > http://ixo-jtag.sourceforge.net/ > > Regards, > -- Hauke D Is there any way to make it permanent yet? nexy2prog is really handy and i've had no problems with it. I e-mailed Digilent back in February to see if they were going to create a Linux client, this is what I got. > Hello ###, > > A Linux port of Adept is currently under development and should be released in a couple of months. Sorry for the inconvenience. > > Please feel free to contact us with any questions you may have. > > Regards, > > Levi Bailey > Digilent Inc. Well, time's up I suppose.Article: 147885
On 5/29/2010 9:57 AM, Michael Kellett wrote: > "Symon"<symon_brewer@hotmail.com> wrote in message > news:htpkq7$435$1@news.eternal-september.org... >> You can't meet the SI requirements of modern sub-ns rise time silicon's >> I/O in 'easy to solder' packages. It's because of the loop area. >> >> BGAs "are harder to probe" made me laugh! I bet you still have a logic >> analyser! >> >> One way to prevent yourself becoming an extinct dinosaur is to splash the >> cash on some decent stimulation tools. Your competitors have. >> >> Syms. > Lighten up Syms ! > > For serious work with hardware I need a logic analyser and a scope !! (if > you can suggest a "stimulation tool" substitute I'm listening). > > I'm totally with Rick on this one - TQFP easy to hand solder, easy to probe, > check, modify etc. > Most of my designs are one or two off, weirdo interfaces for production line > test systems - the largest production run I've ever done with an FPGA was > about 100 off. > > I can see the appeal of BGA for mass production but I'm convinced that TQFP > is cheaper to prototype in low pin counts. A serious FPGA (>20K LUT) in 100 > pin TQFP would be very nice. > But I accept that the number I might buy wouldn't make the supplier very > rich. > > Michael Kellett > Hi Michael, Lighten up? About FPGA design? OK, I'll try! Anyway, it made me laugh, how light do you want? And then you talk about serious work. Talk about bringing the mood down! :-) Anyway, I have a 'scope too. I use it a fair bit, but not as much as LTSpice. I don't have a logic analyser. I have used Chipscope as a last resort, but a simulator like ModelSIM is my preferred tool for catching logic bugs. My spectrum analyser is far more useful than a logic analyser could be. Here's the skinny. You're correct that TQFPs are easier to hand solder than BGAs. Also, they are easier to probe. That's just as well because the SI of a TQFP because of the leads' loop area is poor enough that you may well need to probe them. I would have thought that the kind of ATE type equipment you are making needs to have good SI? When I design test equipment, I would not even consider a leaded part. Especially as, in a pinch, you can reflow a BGA with a toaster oven. Anyway, I don't know your specific circumstances, and I'm sure you have excellent reasons for choosing the parts you do. I would just like to point out that there are some jolly good incentives for ditching leaded parts, and that some investment in decent simulation tools and a toaster oven is the way forward! Cheers, Syms.Article: 147886
On Sat, 22 May 2010 16:50:55 -0700 (PDT), John_H <newsgroup@johnhandwork.com> wrote: >Call me a sadist, but I tend to cruise through the license agreements >and EULAs before installing software to make sure I'm not being >victimized by using someone's application. I wanted to bring my S3E >starter kit back up to prototype Xilinx-based algorithms while >employed by a particularly Altera-friendly group. Loading ISE 12.1, I >not only find lawyer-speak that's longer than Facebook privacy policy >but see that: > > "Webtalk" is a required component to run Webpack. > >A quote from the second page of legalese: "Please note that WebTalk >will collect and transmit certain data that may contain (or be >correlated to reveal, primarily via the Authorization Codes data) >personally identifiable information. By agreeing to this Agreement, >you hereby give your consent (on behalf of Licensee and Users) for >Xilinx to use and disclose this information anywhere in the world for >the purposes and as described in this Agreement." > >Crud. > >Anyone know of the last Webpack I could get that doesn't transmit >things like my constraints, devices, and authorization codes back to >Xilinx? I just want to prototype some stuff and do NOT like my >computer to leak information out into the world beyond my control. At >the moment my form of control is to not install ISE. To not use >Xilinx. There is still yet weirder complication to this issue. Even if you install a regular license and check the webtalk box off, ISE will use a webpack license if the part you're using is available in the webpack and will override your webtalk selection. The only option seems to be to remove the webpack license from your computer. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 147887
On May 30, 3:42=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > There is still yet weirder complication to this issue. Even if you > install a regular license and check the webtalk box off, ISE will use > a webpack license if the part you're using is available in the webpack > and will override your webtalk selection. The only option seems to be > to remove the webpack license from your computer. Hmm, there must be Xilinx customers, who chave quite deeply secret designs, and this chatter must be a real concern to them ? Sounds like the only sure way, is to ring fence the machine from the internet completely - which makes SW updates more time consuming. - and this might even dictate TWO PCs on a designer's desktop : one for the valuable IP designs, and a net-hack that can chatter away ? -jgArticle: 147888
On May 29, 9:32=A0pm, regomodo <regom...@gmail.com> wrote: > On May 28, 3:47 pm, Hauke D <hau...@zero-g.net> wrote: > > > A while back, Andy Ross posted a Perl script that pulls together the > > many steps required to program a Digilent Nexys2 board under Linux: > > >http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/c7... > > > I just wanted to let everyone know that this script, along with the > > firmware it uses, is hosted at the "ixo-jtag" project on SourceForge: > > >http://ixo-jtag.sourceforge.net/ > > > Regards, > > -- Hauke D > > Is there any way to make it permanent yet? nexy2prog is really handy > and i've had no problems with it. > > I e-mailed Digilent back in February to see if they were going to > create a Linux client, this is what I got. > > > Hello ###, > > > A Linux port of Adept is currently under development and should be rele= ased in a couple of months. Sorry for the inconvenience. > > > Please feel free to contact us with any questions you may have. > > > Regards, > > > Levi Bailey > > Digilent Inc. > > Well, time's up I suppose. I tried to run AVR programmer using Wine in Linux. But I cannot manage to do. Hope they are working on their AVR programmer too.Article: 147889
On Sat, 29 May 2010 22:41:03 -0700, -jg wrote: > On May 30, 3:42 pm, Muzaffer Kal <k...@dspia.com> wrote: >> There is still yet weirder complication to this issue. Even if you >> install a regular license and check the webtalk box off, ISE will use a >> webpack license if the part you're using is available in the webpack >> and will override your webtalk selection. The only option seems to be >> to remove the webpack license from your computer. > > Hmm, there must be Xilinx customers, who chave quite deeply secret > designs, and this chatter must be a real concern to them ? > Sounds like the only sure way, is to ring fence the machine from the > internet completely - which makes SW updates more time consuming. - and > this might even dictate TWO PCs on a designer's desktop : one for the > valuable IP designs, and a net-hack that can chatter away ? -jg Or move to a different vendor. Does anyone know if Altera does this kind of Orwellian nonsense? -- Joe Chisolm Marble Falls, Tx.Article: 147890
>On May 28, 12:55=A0pm, "onkars" ><onkars@n_o_s_p_a_m.n_o_s_p_a_m.winlab.rutgers.edu> wrote: >> Hi, >> >> How can I estimate the resoures used by a core generated by CoRE GEn ----= > I >> guess the resource utilization report should give this right? >> >> What do the percentages in the resource utilization report of CoreGEN >> indicate --- is it the percentage of total FPGA resource OR is it >> percentage with respect to the total core size? >> >> Where can I get more details on reading/understanding the resource >> utilization report? >> >> Also how can I find the speed performance of the core -- just an estimate >> -- for the core in isolation is also OK. > >I'm pretty sure the data sheet for each core specifies the core's size >and performance. > >-a > Thanks for the reply. Actually the data sheet gives the utilization and performance numbers of a few configurations --- many many configs are possible (bit-widths, etc.) I would like to know the numbers for my specific configuration. Thank you. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147891
onkars wrote:
> I would like to know the numbers for my specific configuration.
Run synthesis and read the reports.
-- Mike Treseler
Article: 147892I'd agree on the comment on solder bridges. We have a rework of about 0.03% on our BGAs last year. Our TSSOP/TQFP rework rate is something like 100x that. BGAs do get a little tricky when you go down to 0.5mm pitch like we do on our Craignell1 family but 0.8mm and 1mm pitch are easy. The minimum board technology gets more expensive in low volumes although this becomes much less of an issue if you start making 1k+ units. The TQFP I would agree with is that signal integrity is much worse that BGAs typically. Ground bounce effects can be very bad. We have seen customer designs where they had lots of problems when they have used a 2 layer PCB and a TQFP package together. That's not say it can't be done. As yet we have not had any problems on our Polmaddie boards reported and they areTQFP on a 2 layer board. We spent lots of time looking at how we could solve those issues before they happened on these boards and it looks like it paid off. John Adair Enterpoint Ltd. On 28 May, 18:29, Rob Gaddi <rga...@technologyhighland.com> wrote: > On 5/28/2010 10:05 AM, rickman wrote: > > > > > > > I am looking at reducing the cost of a board while improving the > > performance and one way is to add a processor to offload the low > > bandwidth portions of an FPGA design and then reduce the capacity of > > the FPGA. =A0Using an FPGA with 5 volt tolerant I/Os will let me remove > > a couple of quick switch parts as well. =A0This has potential of saving > > a few bucks off the top and greatly improving the usable capacity of > > the device. =A0However... there just don't seem to be *any* FPGAs that > > fit the bill. > > > 5 volt tolerance (a potential bonus, but not required) > > small package/low pin count, not BGA, ~32 usable I/Os, 48 TQFP ideal > > 500 LUTs and 256 bits of memory > > Price<$5 > > > Currently the entire design is in a Lattice XP device with 3k LUTs, > > but is 90% utilized with a recent capability upgrade. =A0I can't even g= o > > with a larger FPGA without also going to a BGA package which drives > > the price up. =A0I don't like BGAs because they take extra space for > > fanout of the signals and they are harder to probe than QFPs. =A0I don'= t > > think any two of these three requirements can be found in the same > > part. Well, maybe CPLDs come in smaller packages at a low cost... > > > I'm just surprised that there isn't more demand for FPGAs in low pin > > count packages. =A0I guess I'm getting to be a dinosaur in my preferenc= e > > for QFPs. =A0Still, I don't think you can even find a FPGA under $10 in > > a BGA package because the pin count is typically higher which drives > > the part cost up. > > > Just some thoughts about my continued frustration in reaching design > > goals. > > > Rick > > My problem with QFPs is that those long leads on 0.5mm pitch are perfect > solder wicks. =A0Our BGA soldering yield is 100%, whereas we have to clea= r > at least one bridge on QFPs about half the time. > > I'd love a 49 ball, 1mm pitch part. =A0With 6/6 rules you could route out > all but the inner 9 balls on the top layer; with 5/5 you could route out > all but the center (which in a sensible world would be ground anyhow). > That would put it at about 8mm on a side while still providing enough IO > pins to do something interesting. > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order- Hide quoted text - > > - Show quoted text -Article: 147893
>On Thu, 27 May 2010 11:00:30 -0500, "Eagle_mk4" ><eagle_mk4@n_o_s_p_a_m.n_o_s_p_a_m.hotmail.com> wrote: > >>And someone can help me with an example for write a random data into any >>address, I mean an example of how should be the module with the input >>signals. > >There should be one in the files you generated with Coregen when you >created the MIG design > >- Brian > The testbench of example folder?? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147894
Hi, The Spartan3 datasheet is very light on the topic of interconnect. I wonder how big the effect of fanout is, on the delay of a route. I'm not talking about "high fanout" signals like CLK, but rather just normal logic signals. For example, in a design I can choose to use fanout=5 (easy), or fanout=4 (with extra cost somewhere else). The distance of the route is about the same in both variants. Will fanout=4 significantly improve the delay of the route? For reference, "significant" for me would be ~0.3ns or more. Thanks, MarcArticle: 147895
>On 21 Apr., 18:15, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: >> On Apr 20, 6:20=A0pm, "stephen.cra...@gmail.com" >> >> <stephen.cra...@gmail.com> wrote: >> > The CTO of Xilinx, during his keynote this morning at the >> > Reconfigurable Architectures Workshop in Atlanta, made mention of the >> > recent announcement of the Virtex 7 architecture. =A0My colleagues and = >I >> > assumed that either the announcement was very recent or not very well >> > publicized as none of us had heard anything official regarding Virtex >> > 7. A subsequent web search returned little except for a white paper on >> > 28nm technology. >> >> > Does anyone know what announcement the CTO was referring to? >> >> Either your colleagues misheard what was said our our CTO, Ivo Bolson, >> mispoke. =A0There has been no announcement of a Virtex-7 FPGA family. >> >> Xilinx did recently announce aspects of future families that will be >> developed on the 28nm process node.http://www.xilinx.com/technology/roadm= >ap/index.htm >> >> Ed McGettigan >> -- >> Xilinx Inc. > >Hi, >in Elektronik issue 8/2010 (bimonthly leading German electronics >magazine) there's a featured article about "The FPGA of the Future". >There is a statement that says :" The fabrication of [Xilinx's] 28nm >devices will take place at Samsung and TSMC. >The Spartan and Virtex product lines will be joined into a single >product family for the 28 nm devices by Xilinx - PROBABLY named >Virtex-7" > >So, the name is in print already. It's NOT mentioned who came up with >it, but unless Xilinx doesn't plan to name this new line totally >different it's an obvious guess. >Rumors travel fast. :-) > >Regards > Eilert > Just read the article. Nice article, but I think the joining of spartan and virtex lines using a combined virtex 7 name is something that the author is guessing, hence not a rumor. Probably there a a number of grains of salt to the argument, and Xilinx has indeed started to design virtex and spartan with the same design team. Therefore it would make sense that the core logic of Virtex and Spartan will converge in the Virtex 7 generation. But i do not believe that will lead to a single line of FPGAs - there will always be the value (<$200, spartan) and the performance (>$500, virtex) lines. The interesting part of the article is that Altera is trying to develop a 28Gb/s transceiver for advanced optical interfaces (100Gb/s using 4 lines, 400Gb/s using 16 lines), which will push Xilinx to do the same. If this is Virtex 7 or Virtex 8 remains to be seen, still waiting to see the ARM core in Virtex 6 FX (or will it be pushed to Virtex 7?). --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147896
I don't have a complete answer to your question, but fanout delay is generated primarily by switch boxes in Xilinx FPGAs. Switchboxes are an integral part of routing and generating fanout, but I would guess that for any reasonable design the dominant factor is the switchboxes involved in routing switches, rather than those used to generate some initial fanout on the output of a CLB. i.e. for a modest fanout, you will go through one switchbox on the output to your CLB, but also several more as your signal gets routed around the chip. I'd guess this to be true for any signal that has sources and destinations that aren't immediately adjacent to one another. If you are really trying to squeeze an extra 300ps out of your design, focus on pipelining and creating good area groups. If you really want low delay routing, the switchbox next to each CLB is unaoidable unless you find a way to use the carry chains, at which point your destination has to be next to the source. Also, a large portion of the fanout is generated along the routing, not immediately next to the source, so it's hard to say exactly how fanout will be generated for an arbitrary design. (i.e. it could be routed onto one line, then be routed off that line at various points to other destinations, rather than faning out at the source). As an anecdotal data point, a high fanout net (~400 destinations) on a V5 design I have handy show minimum delays of about 460ps and maximums of around 9.7 ns. The key thing being that the 460ps destination is right next to the source, while the 9.7ns destination is half way across the chip. But this is a non-critical path for me, so I don't care too much about max the delay. For real insight into how all this works, find a mdeium-large design and look at the routing in FPGA editor. ChrisArticle: 147897
Chris Maryan <kmaryan@gmail.com> wrote: > I don't have a complete answer to your question, but fanout delay is > generated primarily by switch boxes in Xilinx FPGAs. Switchboxes are > an integral part of routing and generating fanout, but I would guess > that for any reasonable design the dominant factor is the switchboxes > involved in routing switches, rather than those used to generate some > initial fanout on the output of a CLB. i.e. for a modest fanout, you > will go through one switchbox on the output to your CLB, but also > several more as your signal gets routed around the chip. I'd guess > this to be true for any signal that has sources and destinations that > aren't immediately adjacent to one another. As I understand it, most FPGAs now use internal buffers on long routing lines. That is why no more true tristate nets. (The tools will implement them using a MUX structure, so maybe you don't notice.) Otherwise, for current CMOS, the load is more the capacitance of the lines, and not so much the driven devices. More fanout will likely result in more wire capacitance, but so will a single long route. Down to about 0.8u CMOS could consider the lines as lumped capacitance, but past that a distributed RC model is needed. But with buffers along the way, the calculation is somewhat different. -- glenArticle: 147898
On May 27, 11:43=A0am, Vivek Menon <vivek.meno...@gmail.com> wrote: > I am using the Xilinx FFT core v6.0 from ISE 10.1 and I am trying to > verify my values with a FFT calculation run on Matlab. > > My FFT ISIM simulation runs fine and the simulation values match with > the bit accurate model provided by Xilinx. But the order of data is > very different from Matlab. My Xilinx FFT block is configured as 4096 > pt Pipelined steaming I/O with natural order for floating point > values. On Matlab, I use the fft function to determine my values. > > For example: This is the result obtained from Xilinx Logicore v6.0 FFT > bit accurate model. LHS are the Xilinx values and the Matlab values > are on the right. Though the first value matches, everything else > differs. > > But on closer observation, the 64th value obtained from Xilinx > simulation is same as the 2nd value, i.e. > xk_re[64] 6002.34 =3D Matlab:f2_r[1] 6002.34 > > Xilinx CoreGen FFT real value xk_re > =A0xk_re[0] 117467 Matlab:f2_r[0] 117467 > =A0xk_re[1] 1180.82 Matlab:f2_r[1] 6002.34 > =A0xk_re[2] 789.918 Matlab:f2_r[2] 126.469 > =A0xk_re[3] -548.049 Matlab:f2_r[3] -3516.04 > =A0xk_re[4] 3580.31 Matlab:f2_r[4] 1111.52 > =A0xk_re[5] -2871.39 Matlab:f2_r[5] 2287.02 > =A0xk_re[6] -1346.19 Matlab:f2_r[6] 753.863 > =A0xk_re[7] 137.655 Matlab:f2_r[7] 1865.09 > =A0xk_re[8] 372.955 Matlab:f2_r[8] 26.8989 > =A0xk_re[9] -914.218 Matlab:f2_r[9] -167.196 > =A0xk_re[10] -463.463 Matlab:f2_r[10] 788.141 > =A0xk_re[11] -875.82 Matlab:f2_r[11] 977.657 > =A0xk_re[12] -56.4141 Matlab:f2_r[12] 1087.54 > =A0xk_re[13] -544.345 Matlab:f2_r[13] 617.382 > =A0xk_re[14] -526.662 Matlab:f2_r[14] 397.022 > =A0xk_re[15] -333.39 Matlab:f2_r[15] 181.981 > =A0xk_re[16] 216.825 Matlab:f2_r[16] 938 > =A0xk_re[17] -1274.68 Matlab:f2_r[17] 237.049 > =A0xk_re[18] -521.784 Matlab:f2_r[18] 256.72 > =A0xk_re[19] -670.137 Matlab:f2_r[19] 897.621 > =A0xk_re[20] -82.1999 Matlab:f2_r[20] 9.97936 > =A0xk_re[21] -119.689 Matlab:f2_r[21] 180.858 > =A0xk_re[22] -905.393 Matlab:f2_r[22] 1481.65 > =A0xk_re[23] -276.808 Matlab:f2_r[23] 557.669 > =A0xk_re[24] -219.717 Matlab:f2_r[24] 823.101 > =A0xk_re[25] -261.175 Matlab:f2_r[25] 272.421 > =A0xk_re[26] -850.324 Matlab:f2_r[26] 552.726 > =A0xk_re[27] -263.26 Matlab:f2_r[27] 960.132 > =A0xk_re[28] -235.821 Matlab:f2_r[28] 678.96 > =A0xk_re[29] 35.2347 Matlab:f2_r[29] 859.29 > =A0xk_re[30] -72.7756 Matlab:f2_r[30] 731.413 > =A0xk_re[31] -518.872 Matlab:f2_r[31] 378.714 > =A0xk_re[32] -249.704 Matlab:f2_r[32] 829 > =A0xk_re[33] -296.007 Matlab:f2_r[33] 378.714 > =A0xk_re[34] -117.027 Matlab:f2_r[34] 731.413 > =A0xk_re[35] -695.503 Matlab:f2_r[35] 859.29 > =A0xk_re[36] 172.311 Matlab:f2_r[36] 678.96 > =A0xk_re[37] -165.246 Matlab:f2_r[37] 960.132 > =A0xk_re[38] -249.19 Matlab:f2_r[38] 552.726 > =A0xk_re[39] 42.4766 Matlab:f2_r[39] 272.421 > =A0xk_re[40] 229.6 Matlab:f2_r[40] 823.101 > =A0xk_re[41] -318.204 Matlab:f2_r[41] 557.669 > =A0xk_re[42] 266.831 Matlab:f2_r[42] 1481.65 > =A0xk_re[43] -1009.16 Matlab:f2_r[43] 180.858 > =A0xk_re[44] -735.485 Matlab:f2_r[44] 9.97936 > =A0xk_re[45] -297.726 Matlab:f2_r[45] 897.621 > =A0xk_re[46] -294.509 Matlab:f2_r[46] 256.72 > =A0xk_re[47] 762.229 Matlab:f2_r[47] 237.049 > =A0xk_re[48] 699.253 Matlab:f2_r[48] 938 > =A0xk_re[49] -213.069 Matlab:f2_r[49] 181.981 > =A0xk_re[50] -413.187 Matlab:f2_r[50] 397.022 > =A0xk_re[51] -349.572 Matlab:f2_r[51] 617.382 > =A0xk_re[52] -63.1866 Matlab:f2_r[52] 1087.54 > =A0xk_re[53] -845.444 Matlab:f2_r[53] 977.657 > =A0xk_re[54] -965.319 Matlab:f2_r[54] 788.141 > =A0xk_re[55] 70.1314 Matlab:f2_r[55] -167.196 > =A0xk_re[56] -157.18 Matlab:f2_r[56] 26.8989 > =A0xk_re[57] -646.377 Matlab:f2_r[57] 1865.09 > =A0xk_re[58] -2769.69 Matlab:f2_r[58] 753.863 > =A0xk_re[59] -2634.43 Matlab:f2_r[59] 2287.02 > =A0xk_re[60] -1729.81 Matlab:f2_r[60] 1111.52 > =A0xk_re[61] -2057.06 Matlab:f2_r[61] -3516.04 > =A0xk_re[62] -5549.6 Matlab:f2_r[62] 126.469 > =A0xk_re[63] -3951.05 Matlab:f2_r[63] 6002.34 > =A0xk_re[64] 6002.34 Matlab:f2_r[64] 555.219 > =A0xk_re[65] 3082.1 Matlab:f2_r[65] 2875 Hard to tell exactly what is going on. The Matlab output is symmetric...the Xilinx output isn't. Here are two possibilities: !. I usually try a simple input sequence with a known output. My favorite is : re_in =3D [0.125, zeros(1,63)]; im_in=3D [0, -0.125, zeros(1,62)]; cmplx_in=3D complex(re_in, im_in) M_out =3D fft(cmplx_in); The output is a sin() or cos() fcn in the real and imag parts of the output (I can't remember which one right now), and if you plot the real and cmplx output components, you'll get an ellipse. 2. Look for being off by an output stride permutation or transpose. 3. Finally, look out for starting the input a few cycles too late. alanArticle: 147899
On May 29, 1:16=A0am, Sharath Raju <brshar...@gmail.com> wrote:
> On May 28, 7:05=A0pm, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On May 28, 9:47=A0am, Sharath Raju <brshar...@gmail.com> wrote:
>
> > > I am afraid I forgot to include the code in the previous email:
>
> > > DBR : Core512 port map (
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 -- Ram A
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ena =3D> ENA,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 enb =3D> ENA,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wea =3D> WE,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 web =3D> WE,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssra =3D> SSR,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssrb =3D> SSR,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clka =3D> CLOCK,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clkb =3D> CLOCK,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addra =3D> addr_1,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addrb =3D> addr_2,
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 douta =3D> DOUT(71 do=
wnto 36),
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 doutb =3D> DOUT(35 do=
wnto 0),
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dina =3D> DIN(71 down=
to 36),
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dinb =3D> DIN(35 down=
to 0)
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 );
>
> > > -- Address Declaration
> > > addr_1 <=3D '0' & ADDR(7 downto 0);
> > > addr_2 <=3D '1' & ADDR(7 downto 0);
>
> > > The code isn't much. Essentially, I am trying to pretend to have a 25=
6
> > > locations X 72 bits deep memory, whereas the BLOCK RAM is physically =
a
> > > 512 locations X 36 bits wide.
>
> > > On May 28, 6:31=A0pm, Sharath Raju <brshar...@gmail.com> wrote:
>
> > > > Hello,
>
> > > > We are working on a project which involves using BLOCK RAMs. Since =
we
> > > > were new to Block RAMs, I (my colleague actually) instantiated a BL=
OCK
> > > > RAM in VHDL using Xilinx's Block RAM IP core.
>
> > > > The question is regarding timing:
>
> > > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device
> > > > specifies the best case (setup + hold) time to be less than 1 ns, a=
nd
> > > > the maximum frequency of operation to be 280 MHz. Worst case figure=
s
> > > > are not specified.
>
> > > > =A0However, we checked the static timing report and found the setup
> > > > times for the data, address and control signals to be approximately=
4
> > > > ns.
>
> > > > Why is there such a substantial difference ?
>
> > The static timing report includes clock to output delays
> > of the driver as well as routing delays in addition to
> > the actual Tsu of the RAM itself. =A0This should be broken
> > into individual parts and well described in the timing
> > report. =A0Generally speaking, you should always assume
> > that routing delays will constitute a significant
> > portion of your timing budget for any path. =A0According
> > to Xilinx, the tools target 60% / 40% as a goal for
> > logic delay / routing delay.
>
> > HTH,
> > Gabor
>
> Thanks gabor .. shall check the static timing report in more detail
> for the routing and clock to out delays.
I checked the timing report..It explicitly mentions the setup time to
be about 4ns.
Here is a section of the report:
Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)
Setup/Hold to clock CLOCK
------------+------------+------------+------------------+--------+
| Setup to | Hold to | | Clock |
Source | clk (edge) | clk (edge) |Internal Clock(s) | Phase |
------------+------------+------------+------------------+--------+
ADDR<0> | 0.792(R)| 0.598(R)|CLOCK_BUFGP | 0.000|
ADDR<1> | 1.335(R)| 0.164(R)|CLOCK_BUFGP | 0.000|
ADDR<2> | 0.574(R)| 0.773(R)|CLOCK_BUFGP | 0.000|
ADDR<3> | 1.590(R)| -0.040(R)|CLOCK_BUFGP | 0.000|
ADDR<4> | 0.729(R)| 0.648(R)|CLOCK_BUFGP | 0.000|
ADDR<5> | 2.400(R)| -0.688(R)|CLOCK_BUFGP | 0.000|
ADDR<6> | 2.837(R)| -1.037(R)|CLOCK_BUFGP | 0.000|
ADDR<7> | 3.441(R)| -1.521(R)|CLOCK_BUFGP | 0.000|
The complete report can be accessed here:
http://sites.google.com/site/brsharath/DBR.twr?attredirects=3D0&d=3D1
and here is the source: http://sites.google.com/site/brsharath/512x36.vhd?a=
ttredirects=3D0&d=3D1
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