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 18 Maj, 13:51, "Eagle_mk4" <eagle_mk4@n_o_s_p_a_m.hotmail.com> >wrote: >> Hi, I=B4m using MIG v3.0 to generate the VHDL code for a DDR SDRAM >> controller. I implement the design but I don=B4t know which is the >> format(values) the inputs signal, as for example app_af_addr, app_mask_da= >ta >> and app_wdf_data. And where do I declare the signals? >> >> Thanks a lot in advance. >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >I'd like to help you but you need to be more precies. > >lutex > I am using MIG v.3.0 for V4 XC4VLX160-FF1513 Development Kit of Avnet. I need to generate the vhdl code for a DDR SDRAM. With the MIG I generate the all vhdl code for the control signals, but the input signals aren´t generate and I don´t know how and where I declare it... Thanks and sorry for my bad English. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147801
>On May 18, 7:51=A0am, "Eagle_mk4" <eagle_mk4@n_o_s_p_a_m.hotmail.com> >wrote: >> Hi, I=B4m using MIG v3.0 to generate the VHDL code for a DDR SDRAM >> controller. I implement the design but I don=B4t know which is the >> format(values) the inputs signal, as for example app_af_addr, app_mask_da= >ta >> and app_wdf_data. And where do I declare the signals? >> >> Thanks a lot in advance. >> >> --------------------------------------- =A0 =A0 =A0 =A0 >> Posted throughhttp://www.FPGARelated.com > >In your MIG-generated directory structure should be a copy >of the user guide that explains the use of these signals. For >earlier versions of MIG this was ug086.pdf. As I recall it is >not very clear about certain things like which address bits >convert to row column and bank, but it has a few timing >diagrams that help you understand the basics of the interface. > >for add_af_addr the lowest address bits map to the >column address, the next bits up are the row address >and the most significant bits are bank. If it hasn't changed >since MIG 2.3, the address has a fixed width of 31 bits, >so you need to add up your column/row/bank sizes to >see how many of these 31 bits are really used. > >app_wdf_data is the write data input and is twice the >width of the external DDR interface so it runs at the >main clock rate rather than twice the rate. To determine >how many words of data you need to provide with each >write command, divide the burst length by two. Also >remember to start a burst on a burst boundary. For >example for a burst length of 4 you would provide two >words of data and the low two bits of add_af_addr >would be 00. > >app_mask_data is ignored if you don't generate the core >with byte masking enabled. If you need to use it, each >bit of the mask corresponds to one byte of app_wdf_data. >A one bit in the mask "masks out" the associated byte. >If you want to write all bytes it should be zero. > >Take a look at the interface description in the user guide to >see the sequence for pushing commands and data into >the core. > >HTH, >Gabor > Thanks for your info, but I have to generate this signals in a new vhdl module or in the top level module?? Jose --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147802
Hi, thank you for your opinions. >I believe that the LUT/mux design on most FPGAs is such >that they won't glitch in the case of a single input changing >with LUT entries that don't change the output. >My guess is that either they don't oscillate >that fast, or that they won't couple even if they do. Is there any FPGA vendor paper available that could clarify these questions ? cheers, hssigArticle: 147803
On May 24, 10:19=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Gabor <ga...@alacron.com> wrote: > > On May 24, 3:58=A0pm, hssig <hs...@gmx.net> wrote: > >> how does an (unclocked) 2:1 multiplexer behave if input B is selected > >> and input A becomes metastable ? Does the metastability of A have an > >> influence on the stability of the mux output at any point of time ? > > For an ideal multiplexer, I'd have to say that input A should > > have no effect if B is selected. =A0However in an FPGA, muxes are > > often built from look-up tables, which could exhibit odd > > behavior if one input stayed in the logic threshold region > > long enough. =A0 > > I believe that the LUT/mux design on most FPGAs is such > that they won't glitch in the case of a single input changing > with LUT entries that don't change the output. =A0One way to > do that would be to implement the 16:1 mux as 15 2:1 mux > chained together. =A0That might be a little too much, but you > are supposed to be able to rely on them not glitching. > > > Think of a LUT as a bunch of ones and zeroes > > feeding a larger (usually 16:1) mux. =A0Then A, B and SEL would > > all be select inputs to the LUT. =A0Theoretically if SEL is > > low, then the output value should not depend on B, but if > > the mux uses decoders and FETs to connect one input at > > a time to the output, and the B input is neither 1 nor 0, > > the output could float. =A0Normally this period of floating > > would be too short for the output to glitch while B is > > transitioning. =A0But a particularly long metastable event > > could float the output long enough for it to change state. > > Such an event would indeed be rare. > > The one that I would wonder about is, if the metastable input > was oscillating at a high frequency, that it might capacitively > couple through. =A0My guess is that either they don't oscillate > that fast, or that they won't couple even if they do. > (With the current high-speed devices, it might not be possible > to oscillate that fast.) > > -- glen I don't think that metastability generally causes oscillation. I would think that as soon as the signals swing one way or the other they should stabilize. Think of a coin landing on its edge. In the metastable case it stands upright for some time before leaning toward heads or tails, but once it leans one way or the other it accelerates to its resting position. Regards, GaborArticle: 147804
[snip] > >Thanks for your info, but I have to generate this signals in a new vhdl >module Yes. >or in the top level module?? > >Jose > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147805
On 5/25/2010 1:49 PM, Gabor wrote: > > I don't think that metastability generally causes oscillation. > I would think that as soon as the signals swing one way or the > other they should stabilize. Think of a coin landing on its > edge. In the metastable case it stands upright for some time > before leaning toward heads or tails, but once it leans one > way or the other it accelerates to its resting position. > > Regards, > Gabor http://www.google.com/images?q=metastability There are some piccies on Philip's site, as well as a whole bunch of stuff about metastability. I post this link in the hope it will head off yet another useless metastability thread. Fat chance. Cheers, Syms.Article: 147806
Gabor <gabor@alacron.com> wrote: (snip, I wrote) >> The one that I would wonder about is, if the metastable input >> was oscillating at a high frequency, that it might capacitively >> couple through. (snip) > I don't think that metastability generally causes oscillation. I believe that it isn't usual, but I am not sure that it isn't possible. > I would think that as soon as the signals swing one way or the > other they should stabilize. Think of a coin landing on its > edge. In the metastable case it stands upright for some time > before leaning toward heads or tails, but once it leans one > way or the other it accelerates to its resting position. Consider the case where the coin is spinning? Or bouncing around on the table before settling down? But maybe the analogy isn't perfect. -- glenArticle: 147807
On May 24, 7:53=A0pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Mon, 24 May 2010 18:32:32 -0500, "k...@att.bizzzzzzzzzzzz" > > > > <k...@att.bizzzzzzzzzzzz> wrote: > >>>>I don't drive the Xilinx software myself, but R, my guy who does, > >>>>uses MAKE files and avoids the top-level GUI, which is apparently > >>>>crap. > > >>>Interesting. =A0I haven't used the latest Xilinx stuff. > > >>>>Xilinx puts pin assignments into a UCF "universal constraints file", > >>>>which we create from the PADS pcb netlist. We tell The Brat what > >>>>signals we prefer on which banks and such, she routes it the way that > >>>>works best, and we make the pin file for Xilinx. Seems to work. > > >>>The point is that the UCF isn't so "universal". =A0VHDL attributes are= (sorta). > > >>The "universal" part has occasioned some humor. It is handy to have > >>the pin numbers in a file off to the side, but we could just as well > >>have taken the PADS netlist and mashed that into VHDL, if VHDL were > >>the way to name pins. For Xilinx, it isn't. > > >It used to be *A* way. =A0Seems they've removed the possibility. =A0Mayb= e it makes > >it too easy to retarget for the competition. =A0;-) > > Speaking of which, we're looking very seriously at cutting over to > Altera for new designs. The Xilinx software is so broken they will > probably never fix it. And the support is ghastly... when you get any > at all. Switching to Altera looks to be safe to do. I haven't designed in any of their parts lately so I won't have to warn you away from any of them. [*]For those who don't know: Every single CPLD I have ever designed in has gone out of production. I like the Altera software (sort of). There VHDL compiler had a major bug in it back when I tried to use one of their parts in a design. Chances are, they have fixed it by now. I didn't use their part. At least with Altera, they understand that without tools to make the bits for them, their parts are useless so they actively try to make the part easy for the tools to work with and make the tools work well. Xilinx's tools are absolutely huge and so hard to figure out that I gave up on their parts fairly early in looking at them. Lattice made some parts that looked interesting but IIRC you could not get the actual datasheet without making a user name and password. I ran away from that in terror. There is no way that a company that makes a good part is going to do stuff like that. Atmel makes some CPLDs. Unfortunately, their fitter doesn't work and they, as far as I know, never fixed it. They promised the fix and just never did it. On that project we ended up switching to Altera and then pulling the plug on the whole effort. Way back when, a company called ICT made some parts that just made it into the CPLD class. They had the best tool for development of CPLD stuff that I have ever seen. This was back in the DOS days. The tool was dead simple to use and just flat worked. Unfortunately for them, I designed in their flagship product. You know the rest of the story. > > JohnArticle: 147808
On May 24, 3:07=A0pm, John Adair <g...@enterpoint.co.uk> wrote: > The other problem you get with old software is the OS. I keep some > machines with NT for times I need to run my old version software. > > John Adair > Enterpoint Ltd. > Take a look at 'vmware' or 'virtualbox'. I have been able to run antique OS's (and applications) on modern hardware using both. RKArticle: 147809
On May 24, 7:53=A0pm, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Mon, 24 May 2010 18:32:32 -0500, "k...@att.bizzzzzzzzzzzz" > > > > <k...@att.bizzzzzzzzzzzz> wrote: > >>>>I don't drive the Xilinx software myself, but R, my guy who does, > >>>>uses MAKE files and avoids the top-level GUI, which is apparently > >>>>crap. > > >>>Interesting. =A0I haven't used the latest Xilinx stuff. > > >>>>Xilinx puts pin assignments into a UCF "universal constraints file", > >>>>which we create from the PADS pcb netlist. We tell The Brat what > >>>>signals we prefer on which banks and such, she routes it the way that > >>>>works best, and we make the pin file for Xilinx. Seems to work. > > >>>The point is that the UCF isn't so "universal". =A0VHDL attributes are= (sorta). > > >>The "universal" part has occasioned some humor. It is handy to have > >>the pin numbers in a file off to the side, but we could just as well > >>have taken the PADS netlist and mashed that into VHDL, if VHDL were > >>the way to name pins. For Xilinx, it isn't. > > >It used to be *A* way. =A0Seems they've removed the possibility. =A0Mayb= e it makes > >it too easy to retarget for the competition. =A0;-) > > Speaking of which, we're looking very seriously at cutting over to > Altera for new designs. The Xilinx software is so broken they will > probably never fix it. And the support is ghastly... when you get any > at all. > > John I've had *very* good responses when I've called Altera and said that I was wanting to migrate. That said, no matter which side of the fence (A<->X) I'm on, it always looks greener on the other side :) RKArticle: 147810
On Tue, 25 May 2010 09:12:05 -0700 (PDT), d_s_klein <d_s_klein@yahoo.com> wrote: >On May 24, 7:53 pm, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Mon, 24 May 2010 18:32:32 -0500, "k...@att.bizzzzzzzzzzzz" >> >> >> >> <k...@att.bizzzzzzzzzzzz> wrote: >> >>>>I don't drive the Xilinx software myself, but R, my guy who does, >> >>>>uses MAKE files and avoids the top-level GUI, which is apparently >> >>>>crap. >> >> >>>Interesting. I haven't used the latest Xilinx stuff. >> >> >>>>Xilinx puts pin assignments into a UCF "universal constraints file", >> >>>>which we create from the PADS pcb netlist. We tell The Brat what >> >>>>signals we prefer on which banks and such, she routes it the way that >> >>>>works best, and we make the pin file for Xilinx. Seems to work. >> >> >>>The point is that the UCF isn't so "universal". VHDL attributes are (sorta). >> >> >>The "universal" part has occasioned some humor. It is handy to have >> >>the pin numbers in a file off to the side, but we could just as well >> >>have taken the PADS netlist and mashed that into VHDL, if VHDL were >> >>the way to name pins. For Xilinx, it isn't. >> >> >It used to be *A* way. Seems they've removed the possibility. Maybe it makes >> >it too easy to retarget for the competition. ;-) >> >> Speaking of which, we're looking very seriously at cutting over to >> Altera for new designs. The Xilinx software is so broken they will >> probably never fix it. And the support is ghastly... when you get any >> at all. >> >> John > >I've had *very* good responses when I've called Altera and said that I >was wanting to migrate. > >That said, no matter which side of the fence (A<->X) I'm on, it always >looks greener on the other side :) > >RK Xilinx probably has better silicon, and it works great. The software is a train wreck. JohnArticle: 147811
On May 25, 8:12=A0am, Symon <symon_bre...@hotmail.com> wrote: > I post this link in the hope it will head off > yet another useless metastability thread. Fat chance. You need to post again right away. The metastability should only really be a problem between your first post and your second post. Two posts should be enough to clear it, but there might be some people who disagree, so maybe you should make two more posts to be on the safe side. PatArticle: 147812
On May 25, 9:30=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Gabor <ga...@alacron.com> wrote: > > (snip, I wrote) > > >> The one that I would wonder about is, if the metastable input > >> was oscillating at a high frequency, that it might capacitively > >> couple through. > > (snip) > > > I don't think that metastability generally causes oscillation. > > I believe that it isn't usual, but I am not sure that it > isn't possible. > > > I would think that as soon as the signals swing one way or the > > other they should stabilize. =A0Think of a coin landing on its > > edge. =A0In the metastable case it stands upright for some time > > before leaning toward heads or tails, but once it leans one > > way or the other it accelerates to its resting position. > > Consider the case where the coin is spinning? =A0Or bouncing > around on the table before settling down? =A0But maybe the > analogy isn't perfect. > > -- glen I was going by the posts about FPGA fabric flip-flops. In the many discussions on metastability, the gurus seemed to say that oscillation is not a typical manifestation in these structures. Of course the chip vendors don't generally want to disclose the actual flip-flop structure, but it makes sense that metastability caused by failure to meet setup and hold time would not generally result in oscillation. Perhaps metastability caused by a runt clock pulse might? In any case, getting back to the point of the original post, my thought was that a metastable state could cause the LUT output multiplexer to go essentially tristate if it is implemented as a decoder driving pass gates. That of course is another internal structure that the chip vendors don't want to give the details of. In any case it is pretty clear that the LUT's in an FPGA are carefully designed not to glitch when an input changes state unless that input changes the output state. It is possible to test that theory by designing some asynchronous sequential logic using LUT's and seeing if it behaves as anticipated. Regards, GaborArticle: 147813
On Tue, 25 May 2010 10:16:54 -0700 (PDT), Patrick Maupin <pmaupin@gmail.com> wrote: >On May 25, 8:12 am, Symon <symon_bre...@hotmail.com> wrote: > >> I post this link in the hope it will head off >> yet another useless metastability thread. Fat chance. > >You need to post again right away. The metastability should only >really be a problem between your first post and your second post. Two >posts should be enough to clear it, but there might be some people who >disagree, so maybe you should make two more posts to be on the safe >side. I'm not sure you're right about that, I think it would be better to remain undecided for a bit, and see what happens. - BrianArticle: 147814
John Adair <g1@enterpoint.co.uk> wrote: >Depending on what you want to achieve there are ways to make boards >simple by using modules like our previously mentioned Darnaw1. There >are also the DIL format Craignell1 http://www.enterpoint.co.uk/component_replacements/craignell.html >and Craignell2 http://www.enterpoint.co.uk/component_replacements/craignell2.html >modules. These modules allow you to develop your own carrier board but >handle the complex and costly BGA bit for you. > >There are other low cost products like our Polmaddie series >http://www.enterpoint.co.uk/polmaddie/polmaddie_family.html offer ways >into FPGA and CPLD technology at not a lot of cost. These particular >boards sell 1 off at GBP 40 (approx USD 60, Euro 50) in one off and >you get a free programming cable (parallel port) for that money. Club >together with a couple of friends and you can get free worldwide >shipping on our web shop if you can get the order over GBP 100. > >All of these products are bought by hobby engineers. Tools for all of >the above are free to download. We also use 0.1 inch/ 2.54mm pitch >headers/sockets a lot to facilitate hobby and student markets with >many customers even building their add ons with simple stripboard. This is definitely a sensible way to go. OTOH it is not very difficult to put a TQFP100 or PQ208 on a board with a simple soldering iron. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 147815
On Tue, 25 May 2010 10:42:46 -0700 (PDT), Gabor <gabor@alacron.com> wrote: >On May 25, 9:30 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> Gabor <ga...@alacron.com> wrote: >> >> (snip, I wrote) >> >> >> The one that I would wonder about is, if the metastable input >> >> was oscillating at a high frequency, that it might capacitively >> >> couple through. >> >> (snip) >> >> > I don't think that metastability generally causes oscillation. >> >> I believe that it isn't usual, but I am not sure that it >> isn't possible. >> >> > I would think that as soon as the signals swing one way or the >> > other they should stabilize. Think of a coin landing on its >> > edge. In the metastable case it stands upright for some time >> > before leaning toward heads or tails, but once it leans one >> > way or the other it accelerates to its resting position. >> >> Consider the case where the coin is spinning? Or bouncing >> around on the table before settling down? But maybe the >> analogy isn't perfect. >> >> -- glen > >I was going by the posts about FPGA fabric flip-flops. In the >many discussions on metastability, the gurus seemed to say that >oscillation is not a typical manifestation in these structures. There may be no oscillation on the metastable FF itself, but remember that it is probably driving all its loads into their linear region. One or more of those loads (e.g. an inverter driven from it) may then oscillate, but the metastable FF itself will not. (In any case, metastable events with any significant probability is easily dealt with in FPGA as has been discussed many times before) - BrianArticle: 147816
On May 22, 6:50=A0pm, John_H <newsgr...@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. =A0I wanted to bring my S3E > starter kit back up to prototype Xilinx-based algorithms while > employed by a particularly Altera-friendly group. =A0Loading ISE 12.1, I > not only find lawyer-speak that's longer than Facebook privacy policy > but see that: > > =A0 "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. =A0By 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? =A0I just want to prototype some stuff and do NOT like my > computer to leak information out into the world beyond my control. =A0At > the moment my form of control is to not install ISE. =A0To not use > Xilinx. > > Hey - at least it's not like Cadence who says that anything I send > them - designs, etc - effectively becomes public domain. =A0But it > leaves a seriously bad taste in my mouth. > > - John_H Altera does this as well, but offers the carrot approach instead. Turn on web talk, and you get to run SignalTap. Xilinx apparently is going the other route, which I find a bit troubling. However, it is easy enough to deal with. Install a windows firewall, and block the application from sending. Unfortunately, this is becoming more and more common, and you would be surprised at how much traffic comes out of the average PC without the owners knowledge these days. If you want to be absolutely sure your firewall is working, run Wireshark on another system (or, if you are the trusting sort, the same machine), fire off a build, and see if anything crosses the wire that looks like it came from a Xilinx tool. It's using https, so you will probably have to filter on headers.Article: 147817
On Tue, 25 May 2010 20:23:36 +0000, Nico Coesel wrote: > John Adair <g1@enterpoint.co.uk> wrote: [...] >>All of these products are bought by hobby engineers. Tools for all of >>the above are free to download. We also use 0.1 inch/ 2.54mm pitch >>headers/sockets a lot to facilitate hobby and student markets with many >>customers even building their add ons with simple stripboard. > > This is definitely a sensible way to go. Seconded. The Drigmorn2 is a lovely little board -- 32MiB SDRAM, onboard SPI flash, switches, HD44780 LCD, and a ton of LEDs. Debugging it is a DREAM, especially when you can just plug a Harwin pin header into the LHS/ RHS headers, wire in a logic analyser pod and watch as closely as you like. The only thing I don't like about it is the ISSI SDRAM -- the refresh rate figures in the datasheet are incorrect. Use 4096 cycles per 32ms (the refresh rate for the "Industrial" spec part) and it's fine, use 4096- in-64ms (the "Commercial" spec rating) and you get random data corruption issues. I suspect the section on Auto Refresh has been copy-pasted from a datasheet for a different part and not checked against the tested specification... but that's just conjecture. The other possibility is that the part on my DM2 is a mis-marked Ind Temp part, but the laser-markings say it *should* be a -7BL, or a 7ns part in Pb-free BGA... if it was ind-spec it *should* have been marked "-7BLI"... > OTOH it is not very difficult to put a TQFP100 or PQ208 on a board with > a simple soldering iron. Yeah, tack down a few pins at a corner, then coat the pins in paste flux and drag-solder. Clean up with solder wick and you're done. If you're not a fan of manual labour you can use solder paste and a hot-air reflow station, but drag soldering is usually quicker... not to mention more reliable :) -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 147818
I've got a Spartan 6 design that I'm working with under ISE 11.5. A code block that I would expect to take up about 200 LUTs is taking 800 instead. 600 LUTs wouldn't be the end of the world, except I'm planning to replicate this block 32 times, which puts me well over the top. So the question becomes where are all of the LUTs going? There's nothing in the XST status report for the section that would imply anywhere near this much utilization. I've tried looking over the RTL schematic; it's difficult to read and from what I could make out, there still wasn't anything to explain all those LUTs. Then I tried looking through the technology schematic instead. The viewer took forever to open the schematic, and when I finally got it open it took better than a minute any time I wanted to refresh the screen. Needless to say, this got me nowhere. So, I'm out for advice. Any suggestions on figuring out just where all of those LUTs are going? Thanks, Rob -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 147819
On Tue, 25 May 2010 06:38:05 -0700, MooseFET wrote: > Switching to Altera looks to be safe to do. I haven't designed in any > of their parts lately so I won't have to warn you away from any of them. I'm quite fond of them. My first "proper" FPGA devkit was a DE1 (bought mainly because it had a good price-performance ratio and the Minimig-DE1 team were porting Minimig to it) so I've got a bit of a 'soft spot' for ALTR. I will, however, admit that the first PLD I ever used was a Lattice GAL; their insistence that I needed a "Lattice Approved" programmer for it was a bit offputting until I found out about (and built a) GALBlast. Software was mediocre, I used to use Atmel-WinCupl, tried to learn registered logic but couldn't stand the syntax for that. All my GALs ended up being used as address decoders in my 6502 computer. First CPLD I used was a Xilinx XC9572XL... back in the days when Windows 98 was king, and you only had Win2000 if you were on the beta team. I'm a compulsive hoarder of LCD displays, and had a couple of direct-drive ones in my scrap bin. Spent the afternoon reverse engineering the display pinouts with a Fluke 25 DMM, then hooked up the CPLD and reversed the pixel shift order. Good fun. > I like the Altera software (sort of). There VHDL compiler had a major > bug in it back when I tried to use one of their parts in a design. > Chances are, they have fixed it by now. I didn't use their part. I usually use the Verilog side of things, though occasionally do mixed- mode (Vlog+VHDL) when I have a VHDL IP core I need to use. That's pretty rare though. > Xilinx's tools are absolutely huge and so hard to figure out that I gave > up on their parts fairly early in looking at them. I started learning ISE because I'd just bought a Drigmorn2. I figured Xilinx's free dev tools would be about as good as Altera's... how wrong I was! Just getting the SDRAM timing right has been an exercise that would only appeal to a masochist. I finally figured it out at nearly 11:45 last night... kick the refresh timing down, then force everything SDRAM related into an IOB, set the slew rate to FAST, and figure out what to set the phase-shift of the DCM to. When I did this on the DE1, Quartus picked up most of what I was doing, and all I had to set was the PLL phase-shift. Not bad. I think I had the LatticeMico32 core up and running in a few hours, and SDRAM a day or so after that. > Lattice made some parts that looked interesting but IIRC you could not > get the actual datasheet without making a user name and password. I ran > away from that in terror. There is no way that a company that makes a > good part is going to do stuff like that. Can't say I've tried Lattice's FPGAs. I looked at them a few years ago and basically discounted them because I couldn't get hold of them (although I could get a programming cable... for £595, plus ~£2k for the ispLEVER software -- the cable alone was more expensive than XLNX's then- current offering IIRC) > Way back when, a company called ICT made some parts that just made it > into the CPLD class. They had the best tool for development of CPLD > stuff that I have ever seen. This was back in the DOS days. The tool > was dead simple to use and just flat worked. Unfortunately for them, I > designed in their flagship product. You know the rest of the story. That would be the ICT PEEL series, right? Allegedly still in production today -- ICT went bust, then Anachip bought the PLD product line, and Anachip were bought by Diodes Inc. The datasheets aren't on DI's website, but Mouser list the PEEL series as current products. If you're hellbent on using SPLDs, the GAL series are still the best (IMO), but these days you're better off looking at a small CPLD like a Xilinx XC9500XL, CoolRunner or one of the Altera MAX-II parts... for a start they tend to be equal in price to (or cheaper than) the SPLDs. -- Phil. usenet10@philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current yearArticle: 147820
Rob Gaddi <rgaddi@technologyhighland.com> wrote: > I've got a Spartan 6 design that I'm working with under ISE 11.5. A > code block that I would expect to take up about 200 LUTs is taking 800 > instead. 600 LUTs wouldn't be the end of the world, except I'm planning > to replicate this block 32 times, which puts me well over the top. How full is the FPGA that you are targeting? If not so full, I believe that the tools don't try so hard. Well, actually the LUT count shouldn't be so far off, but the CLB count can change, as it doesn't fill each CLB. Otherwise, without knowing about the design it is hard to say. Can you say a little about the logic? How many counters, adders, RAMs. Maybe it is using CLB for RAM, instead of BRAM? -- glenArticle: 147821
On May 25, 5:32=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > I've got a Spartan 6 design that I'm working with under ISE 11.5. =A0A > code block that I would expect to take up about 200 LUTs is taking 800 > instead. =A0600 LUTs wouldn't be the end of the world, except I'm plannin= g > to replicate this block 32 times, which puts me well over the top. > > So the question becomes where are all of the LUTs going? =A0There's > nothing in the XST status report for the section that would imply > anywhere near this much utilization. =A0I've tried looking over the RTL > schematic; it's difficult to read and from what I could make out, there > still wasn't anything to explain all those LUTs. =A0Then I tried looking > through the technology schematic instead. =A0The viewer took forever to > open the schematic, and when I finally got it open it took better than a > minute any time I wanted to refresh the screen. =A0Needless to say, this > got me nowhere. > > So, I'm out for advice. =A0Any suggestions on figuring out just where all > of those LUTs are going? > > Thanks, > Rob > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order A good technology view will make the world of difference. But it seems Xilinx isn't giving you that. I used the Synplify synthesizer's HDL Analyst to get a superb technology view that allowed me to understand the occasional oddity the synthesizer would produce from my code. I found that technology viewer to be a truly top-notch product and sincerely helpful in keeping a design on track. I've only glanced at the Xilinx technology viewer, seeing that it looked like a last-gen VW beetle compared to a modern day Lexus in the HDL Analyst. It may do the job but it won't be a comfortable job if it gets too involved.Article: 147822
On 5/25/2010 10:32 PM, Rob Gaddi wrote: > > So the question becomes where are all of the LUTs going? > > Thanks, > Rob > Does ISE11.5 have FPGA editor? Syms.Article: 147823
On Tue, 25 May 2010 06:38:05 -0700 (PDT), MooseFET <kensmith@rahul.net> wrote: >On May 24, 7:53 pm, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Mon, 24 May 2010 18:32:32 -0500, "k...@att.bizzzzzzzzzzzz" >> >> >> >> <k...@att.bizzzzzzzzzzzz> wrote: >> >>>>I don't drive the Xilinx software myself, but R, my guy who does, >> >>>>uses MAKE files and avoids the top-level GUI, which is apparently >> >>>>crap. >> >> >>>Interesting. I haven't used the latest Xilinx stuff. >> >> >>>>Xilinx puts pin assignments into a UCF "universal constraints file", >> >>>>which we create from the PADS pcb netlist. We tell The Brat what >> >>>>signals we prefer on which banks and such, she routes it the way that >> >>>>works best, and we make the pin file for Xilinx. Seems to work. >> >> >>>The point is that the UCF isn't so "universal". VHDL attributes are (sorta). >> >> >>The "universal" part has occasioned some humor. It is handy to have >> >>the pin numbers in a file off to the side, but we could just as well >> >>have taken the PADS netlist and mashed that into VHDL, if VHDL were >> >>the way to name pins. For Xilinx, it isn't. >> >> >It used to be *A* way. Seems they've removed the possibility. Maybe it makes >> >it too easy to retarget for the competition. ;-) >> >> Speaking of which, we're looking very seriously at cutting over to >> Altera for new designs. The Xilinx software is so broken they will >> probably never fix it. And the support is ghastly... when you get any >> at all. > >Switching to Altera looks to be safe to do. I haven't designed in any >of their parts lately so I won't have to warn you away from any of >them. > >[*]For those who don't know: Every single CPLD I have ever designed >in has >gone out of production. > >I like the Altera software (sort of). There VHDL compiler had a major >bug in it back when I tried to use one of their parts in a design. >Chances are, they have fixed it by now. I didn't use their part. > >At least with Altera, they understand that without tools to make the >bits for them, their parts are useless so they actively try to make >the part easy for the tools to work with and make the tools work well. > >Xilinx's tools are absolutely huge and so hard to figure out that I >gave up on their parts fairly early in looking at them. > >Lattice made some parts that looked interesting but IIRC you could not >get the actual datasheet without making a user name and password. I >ran away from that in terror. There is no way that a company that >makes a good part is going to do stuff like that. > >Atmel makes some CPLDs. Unfortunately, their fitter doesn't work >and they, as far as I know, never fixed it. They promised the fix >and just never did it. On that project we ended up switching to >Altera and then pulling the plug on the whole effort. You forgot Actel. Some of their parts are interesting, though LUT3s are quite limiting and their choice of packages isn't that great. They have some *really* low power stuff and the new mixed-signal with embedded hard core processor stuff is quite interesting. I find it a huge advantage to not commit to one vendor. Well, I should say, it's an advantage for the small designs we do. If I were using at the larger Virtex or Stratix parts I'd likely have a different opinion (BTDT).Article: 147824
On 5/25/2010 2:54 PM, glen herrmannsfeldt wrote:
> Rob Gaddi<rgaddi@technologyhighland.com> wrote:
>> I've got a Spartan 6 design that I'm working with under ISE 11.5. A
>> code block that I would expect to take up about 200 LUTs is taking 800
>> instead. 600 LUTs wouldn't be the end of the world, except I'm planning
>> to replicate this block 32 times, which puts me well over the top.
>
> How full is the FPGA that you are targeting? If not so full, I
> believe that the tools don't try so hard. Well, actually the LUT
> count shouldn't be so far off, but the CLB count can change, as
> it doesn't fill each CLB.
>
> Otherwise, without knowing about the design it is hard to say.
>
> Can you say a little about the logic? How many counters, adders, RAMs.
>
> Maybe it is using CLB for RAM, instead of BRAM?
>
> -- glen
Sure. The widget in question does 8 pole IIR filtering of 16 bit data
using 48-bit internal data paths. The actual add/multiply/add math is
taken care of by a subblock that uses a DSP48 slice and 222 LUTs that
I'm not counting towards the 800.
The block I'm looking at is the wrapper that sequences the math
operations and holds the internal states. The logic infers two 48 bit
LUT RAMs, one dual port, and one quad port. There's a 24-bit LUT RAM
and a 24 bit adder that I use to implement an FIR prefilter (the 8 zeros
at z=-1 that you get from the bilinear transform of an 8 pole filter).
There's an FSM with four states, and a couple of 3 bit counters. There
are two 18 bit comparators, but most of the LSBs of them should optimize
out.
I'll append the code here. I'm not bothering to include pkg_bus as
well, but it just defines a simple WISHBONE bus and a few constants.
--
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.NUMERIC_STD.all;
use IEEE.STD_LOGIC_MISC.all;
use work.pkg_bus.all;
-- Xilinx specific macro library
-- library UNISIM;
-- use UNISIM.VComponents.all;
entity filter is
port (
-- Data path
din : in signed(15 downto 0);
nd : in boolean;
dout : out signed(15 downto 0);
drdy : out boolean;
-- Coefficient path
WB_IN : in t_wb_mosi;
WB_OUT : out t_wb_miso;
WB_SYS : in t_wb_sys
);
end entity filter;
architecture Behavioral of filter is
alias clk : std_logic is WB_SYS.CLK_I;
alias rst : std_logic is WB_SYS.RST_I;
-- Component declaration of the "filter_math" unit defined in
-- file: "./src/vhdl/filter_math.vhd"
component filter_math
port(
data : in SIGNED(47 downto 0);
pre : in SIGNED(47 downto 0);
post : in SIGNED(47 downto 0);
k : in SIGNED(47 downto 0);
lsd_nd : in BOOLEAN;
ichg : out BOOLEAN;
irdy : out BOOLEAN;
y : out SIGNED(47 downto 0);
lsd_rdy : out BOOLEAN;
msd_rdy : out BOOLEAN;
clk : in STD_LOGIC);
end component;
for all: filter_math use entity work.filter_math(Xilinx_DSP48A1);
-- We're going to use a whole mess o' RAMs to store various
-- and sundry.
subtype t_data is signed(47 downto 0);
constant POLES : integer := 8;
constant MAX_IDX : integer := POLES-1;
-- Data memory is S3.45.
subtype t_idx is integer range 0 to MAX_IDX;
type t_ram is array(t_idx) of t_data;
signal ram_dat : t_ram := (others => (others => '0'));
subtype t_uns_idx is unsigned(2 downto 0);
signal write_idx : t_uns_idx;
signal read_idx : t_uns_idx;
-- Coefficient memory is also S3.45, but since we're
-- writing it from a 16 bit data bus, we need to be
-- able to access it a word at a time.
--
type t_coefram is array(t_idx) of t_wb_data;
signal ram_k_hi : t_coefram := (others => (others => '0'));
signal ram_k_md : t_coefram := (others => (others => '0'));
signal ram_k_lo : t_coefram := (others => (others => '0'));
-- As seen from the memory bus, the coefficients are
-- 64 bits long. The uppermost word of this is shared
-- between all coefficients, and is the filter control
-- word.
signal fcw : t_wb_data;
-- Bits 2:0 are POLES_USED, which should be an odd number
-- equal to the number of poles for this filter - 1. Any
-- even number here, including zero, will code for no filter.
alias poles_used : std_logic_vector is fcw(2 downto 0);
-- Hook the data up to the math core
signal data : t_data;
signal pre : t_data;
signal post : t_data;
signal k : t_data;
signal y : t_data;
signal go : boolean;
signal lsd_nd : boolean;
signal ichg : boolean;
signal irdy : boolean;
signal lsd_rdy : boolean;
signal msd_rdy : boolean;
-- Downstream of the math core we'll apply a cascade of 2 pole
-- boxcar filters in order to put some zeros. One bit growth per
-- stage brings us to S1.23 when we're done.
subtype t_fir_data is signed(din'length + POLES - 1 downto 0);
type t_firram is array(t_idx) of t_fir_data;
signal fir_cascade : t_firram := (others => (others => '0'));
signal fir_idx : t_uns_idx;
signal fir_din : t_fir_data;
-- Internal states of things
signal fir_drdy : boolean;
signal use_fir_data : boolean;
type t_state is (IDLE, FIR, IIR, RESET);
signal state : t_state := RESET;
-- LFSR noise generator. When we first extend the 16 bit data to 24
-- bits for the FIR filter, adding this noise in below the LSB helps
-- make sure the IIR filters don't get into long, drawn out settlings.
signal lfsr : std_logic_vector(22 downto 1) := (others => '0');
begin
-------------------------------------------------------------------------
-- Make sure our constants are compiled correctly.
-------------------------------------------------------------------------
assert (2**write_idx'length = POLES)
report "Length of RAM index does not correspond to number of poles."
severity failure;
-------------------------------------------------------------------------
-- Connect up the asynchronous data paths.
-------------------------------------------------------------------------
-- FIR data is in S1.23, the math core is expecting S3.45
data <= SHIFT_LEFT(RESIZE(fir_din, data'length), 45-23) when
use_fir_data
else y;
lsd_nd <= fir_drdy when use_fir_data else
lsd_rdy;
-- Everything else comes out of the RAMs. ram_k has one r/w port and one
-- read port, ram_dat has one write port and two read ports.
--
pre <= ram_dat(TO_INTEGER(read_idx or "001"));
post <= ram_dat(TO_INTEGER(read_idx));
k <= SIGNED(ram_k_hi(TO_INTEGER(read_idx))) &
SIGNED(ram_k_md(TO_INTEGER(read_idx))) &
SIGNED(ram_k_lo(TO_INTEGER(read_idx)));
-- Instantiate our math core.
MATH : filter_math
port map(
data => data,
pre => pre,
post => post,
k => k,
lsd_nd => lsd_nd,
ichg => ichg,
irdy => irdy,
y => y,
lsd_rdy => lsd_rdy,
msd_rdy => msd_rdy,
clk => clk
);
-------------------------------------------------------------------------
-- WISHBONE coefficient readback.
-------------------------------------------------------------------------
WB_READBACK: process(WB_IN, fcw, ram_k_hi, ram_k_md, ram_k_lo)
variable read_addr : integer range 0 to MAX_IDX;
variable word_addr : integer range 0 to 3;
begin
read_addr := TO_INTEGER(WB_IN.ADDR(1 + read_idx'length downto 2));
word_addr := TO_INTEGER(WB_IN.ADDR(1 downto 0));
WB_OUT <= WB_BADA_SLAVE;
if read_addr <= MAX_IDX then
case word_addr is
when 0 => WB_OUT.DAT <= fcw;
when 1 => WB_OUT.DAT <= ram_k_hi(read_addr);
when 2 => WB_OUT.DAT <= ram_k_md(read_addr);
when 3 => WB_OUT.DAT <= ram_k_lo(read_addr);
end case;
end if;
end process WB_READBACK;
-------------------------------------------------------------------------
-- Wrangle the big state machine.
-------------------------------------------------------------------------
MACHINE: process
variable write_addr : integer range 0 to 31;
variable word_addr : integer range 0 to 3;
variable current : t_data;
variable unclamped : signed(17 downto 0); -- S3.15 number
begin
wait until rising_edge(clk);
drdy <= false;
fir_drdy <= false;
if nd then
assert (state = IDLE)
report "New data request before IDLE state."
severity error;
end if;
case state is
when IDLE =>
-- Hold things in the start state.
use_fir_data <= true;
read_idx <= (others => '0');
write_idx <= (others => '0');
if nd then
if (poles_used(0) = '0') then
-- Allow for no filter at all
dout <= din;
drdy <= true;
state <= IDLE;
else
-- Start our FIR filter with din at the MSBs.
state <= FIR;
fir_idx <= UNSIGNED(poles_used);
fir_din <= SHIFT_LEFT(
RESIZE(din & lfsr(lfsr'high), fir_din'length),
fir_din'length - din'length - 1
);
end if;
else
state <= IDLE;
end if;
when FIR =>
-- Store the value, push the average forward.
fir_cascade(TO_INTEGER(fir_idx)) <= fir_din;
fir_din <= SHIFT_RIGHT(fir_din, 1) +
SHIFT_RIGHT(fir_cascade(TO_INTEGER(fir_idx)), 1);
if (fir_idx = 0) then
-- Start the IIR filter. Repurpose the FIR index to count
-- down the number of poles to do.
state <= IIR;
fir_drdy <= true;
fir_idx <= UNSIGNED(poles_used);
else
fir_idx <= fir_idx - 1;
end if;
when IIR =>
-- The main responsibilities are updating
-- the pointers and updating the stored data.
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;
write_idx <= write_idx + 1;
fir_idx <= fir_idx - 1;
if (fir_idx = 0) then
state <= IDLE;
write_idx <= (others => '0');
-- We've treated the data as S3.45 all the
-- way through. First, remap it to S3.15
unclamped := RESIZE(SHIFT_RIGHT(y, 45-15), 18);
-- Now clamp any excess.
if TO_INTEGER(unclamped) >= 2**15 then
dout <= x"7FFF";
elsif TO_INTEGER(unclamped) <= -(2**15) then
dout <= x"8001";
else
dout <= RESIZE(unclamped, 16);
end if;
drdy <= true;
end if;
elsif ichg and not lsd_nd then
-- We can advance the read index ahead of
-- time.
read_idx <= write_idx + 1;
if (fir_idx = 0) then
use_fir_data <= true;
else
use_fir_data <= false;
end if;
end if;
when RESET =>
-- Initialize the states for both filters
ram_dat(TO_INTEGER(write_idx)) <= (others => '0');
fir_cascade(TO_INTEGER(fir_idx))<= (others => '0');
if (fir_idx = 0) then
write_idx <= (others => '0');
state <= IDLE;
else
write_idx <= write_idx + 1;
fir_idx <= fir_idx - 1;
end if;
end case;
-- Allow bus writes to the coefficient RAM
if is_write(WB_IN) then
write_addr := TO_INTEGER(WB_IN.ADDR(6 downto 2));
word_addr := TO_INTEGER(WB_IN.ADDR(1 downto 0));
if write_addr <= MAX_IDX then
case word_addr is
when 0 => fcw <= WB_IN.DAT;
when 1 => ram_k_hi(write_addr) <= WB_IN.DAT;
when 2 => ram_k_md(write_addr) <= WB_IN.DAT;
when 3 => ram_k_lo(write_addr) <= WB_IN.DAT;
end case;
end if;
end if;
-- Advance the LFSR
lfsr <= lfsr(21 downto 1) & (lfsr(22) xnor lfsr(21));
-- Handle the reset.
if (rst = '1') then
write_idx <= (others => '0');
read_idx <= (others => '0');
fir_idx <= (others => '1');
fcw <= (others => '0');
use_fir_data <= true;
state <= RESET;
end if;
end process;
end architecture Behavioral;
--
Rob Gaddi, Highland Technology
Email address is currently out of order
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