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
John_H wrote: > > HDL, not schematics, yes! yes! > Verilog and VHDL are both appropriate to the task. > It's a little like the age old question (probably still valid in your corner of > this world: "Coke or Pepsi?" > If you have tools for and/or experienced designers that use one HDL, it's a > great way to go. I use schematics and drink "No-Name Cola". One advantage schematics may be ( with a good macro library ) for the large amount of small TTL projects that are around. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics.Article: 32976
Achlys4now@yahoo.com (Achlys) writes: > These are repeatable, hard failures that are temperature insensitive. > Replacing the IC usually fixes it. The design(s) is now fairly mature > and is being functionally enhanced. Replacing the suspect block ram > with a different resource internally can fix the problem. Same design, > new placement with both routes meeting the timing constraints. Yikes! > Not good for field upgrades. I've had this kind of problem with FPGAs. A design worked in some devices, and it didn't in other. Re-P&R solved the problem, and the it came back after the next alteration of the design. I can't remember if temperature changed it, but I think not. The failure/success was very deterministic. The error? Having an unsynchronized signal going into a statemachine. One part of the statemachine went one way, the other part did not. It took we a while to figure that one out. It was strange to see what can happen if you aren't careful. I have no idea if this is applicable to your case, it just sounded so familiar. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 32977
HDL, not schematics, yes! yes! Verilog and VHDL are both appropriate to the task. It's a little like the age old question (probably still valid in your corner of this world: "Coke or Pepsi?" If you have tools for and/or experienced designers that use one HDL, it's a great way to go. You'll also find a new newsgroup to visit - comp.lang.verilog or comp.lang.vhdl. If you get in the habit of using HDL early on, you'll be in great shape for some interesting design challenges. - John Noddy wrote: > Hi, > > As you've guessed from recent posts, I'm very new to using FPGAs (couple of > months). I've been spending my time implementing schematic design entries > (using Foundation ISE). This brings me to my question? Should I rather be > attempting to implement my designs in VHDL instead? My experience with VHDL > is the Designer's Guide to VHDL! > > Any suggestions? > > AdrianArticle: 32978
John_H <johnhandwork@mail.com> writes: > Verilog and VHDL are both appropriate to the task. > It's a little like the age old question (probably still valid in > your corner of this world: "Coke or Pepsi?" Actually, it's more like "Coke or a beer?". One is common in the US, the other you can have more fun with... Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 32979
My feeling on this is HDLs give you more flexibility when it comes to parameterizing your designs, and much better testbenches. Also, an HDL doesn't require a proprietary view to browse the design (although it may need a specific version of the synthesizer to generate exactly what you intended). Other than these points, I find that properly done schematics or HDL are appropriate. For either, proper use of hierarchy plays a much bigger role in reusability, readability, documentation, and troubleshooting than does the choice of a design entry tool. I actually like to discourage newbies to FPGAs and/or digital design using HDLs, as the abstraction tends to hide poor design practice, as well as the obvious architectural tailoring you can easily do in the design if you are close to the underlying chip architecture. HDLs make it too easy to design something that is very difficult/expensive in hardware and many times the designer doesn't even realize it. VHDL is a a powerful tool, but it does not make a lousy design magically good and since it tends to hide the details it may not be obvious the design is lousy. Magnus Homann wrote: > John_H ?johnhandwork@mail.com? writes: > > ? Verilog and VHDL are both appropriate to the task. > > ? It's a little like the age old question (probably still valid in > ? your corner of this world: "Coke or Pepsi?" > > Actually, it's more like "Coke or a beer?". One is common in the US, the other > you can have more fun with... > > Homann > -- > Magnus Homann, M.Sc. CS ? E > d0asta@dtek.chalmers.se -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 32980
There are ways around distributing source. For simulation you can either include a behavioral model that is bit and clock cycle true (this is what we do for our HDTV cores), or you can distribute compiled libraries for the major simulators (for example, modelsim distributes the ieee libraries compiled....no source) so that the design can be simulated with the actual design without divulging the source. Yes, virtually enything engineered by man can also be reverse engineered, but you can take steps to make it require more effort. In the license agreement, we put a clause prohibiting any decompiling of the machine files...of course the only effect is to give your lawyer a leg to stand on if you catch someone. With adequate documentation and suitable simulation models or compiled libraries, an end user does not have to have visibility into the source. Look at the xilinx coregen library for example. Very few of those have any source provided. Steve Casselman wrote: > ? The same problem exists for distributing source code for software. > ? Non-disclosure agreements, licensing and sueing, are the only things I can > ? think ok. > > You have the same problem with any program. You can disassemble anything and > reverse engineer anything. You might consider a Open Source type of thing > where you just sell the code and trust no one will distribute it (with > licensing agreements). I think most of the people who buy IP really need to > have source to simulate it right and what not. Just charge for it. > > Steve -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 32981
Achlys wrote: > Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<3B4DFEB5.3EB92611@flukenetworks.com>... > > Achlys wrote: > > > > > > Is anyone experiencing block ram failures in Xilinx Virtex-E devices? > > > We've seen a condition where different bit files will cause hard > > > failures on a small percentage of the parts. > > . . . > > > Re-synthesising the design helps sometimes but not always. > > > Working boards will fail with new bit files. We've seen the failure on > > > multiple parts and on multiple designs. > > > > > > > > Sounds like a race condition somewhere. > > Did static timing run ok? > > > > > > > Hi Mike, > > Static timing is ok - and we have updated timing files (Service pack > 8). As you probably know Xilinx had incorrect timing files. When we > first started this project we had the intermittent type problems > caused by race conditions. This was from DesignManager reporting OK > timings which were actually 1-2ns over. > > These are repeatable, hard failures that are temperature insensitive. > Replacing the IC usually fixes it. The design(s) is now fairly mature > and is being functionally enhanced. Replacing the suspect block ram > with a different resource internally can fix the problem. Same design, > new placement with both routes meeting the timing constraints. Yikes! > Not good for field upgrades. > > Sound familiar to anyone? > > Thanks > > > > > --Mike Treseler Have you tried a post-route simulation with the clock speed(s) set to the timing analysis values ? I have had one case, quite a long time ago, where the timing analysis said the design was o.k. but it failed simulation. Looking further I traced this down to a change in the default value of some of the timing path control flags from enabled to disabled - notably "reg_sr_clk" & "ram_d_o". Note also that I regularly over-clock Virtex-E designs by between 20-30% with no problems so there is a fair bit of margin in worst case timing.Article: 32982
In article <994923743.528258@turtle.ru.ac.za>, "Noddy" <g9731642@campus.ru.ac.za> wrote: >Hi, > >As you've guessed from recent posts, I'm very new to using FPGAs (couple of >months). I've been spending my time implementing schematic design entries >(using Foundation ISE). This brings me to my question? Should I rather be >attempting to implement my designs in VHDL instead? My experience with VHDL >is the Designer's Guide to VHDL! > Most people, I'm sure, are going to tell you to use HDL's. I'm going to register a different opinion and say that to make a blanket statement, that such-and-such a tool is the way to go, limits your options and may not be the best way to go. I think it's a case of a different tool for a different type of job. It really depends what it is that you're trying to do that will determine what's the best tool. Since you're using Xilinx (as the Foundation software indicates), I'll go over the plusses and minuses of each. You have 4 basic options: HDL, state machine, schematic, or FPGA editor. These roughly correspond to decreasing levels of abstraction. HDL's excel in complex but well-defined designs, where you know exactly what it is that your logic must do, but what it needs to do is complex and involved. If you think in an "algorithmic" or software-like way, in other words, you view your logic as "code" that you need to execute, HDL's will be the tool you'll be most comfortable with. They let you describe your logic in a source-code-like manner, and they'll let you do some very involved stuff. The tools for HDL have extraordinary sophistication, with plenty of verification and simulation options, lots of different flavors of synthesis entry, and usually a great many options in the program itself. HDL's are also, oddly, very good for really quick, simple logic functions that you don't feel like taking the time to figure out how the hardware would have to be for them. The downside of HDL's is that the abstraction isolates you very much from the details of what's going on in the hardware. Typically you don't have ultimate control over how the software will actually implement your design on the chip. Furthermore, although the range of functions you can implement is amazing, abstracting the functionality still means that at a certain level you limit your design to the kinds of logic functions and blocks that the designers of the software envisioned. In other words, HDL's aren't your best bet if you're looking to tweak the last inch of performance, or utilization from your FPGA, or if you're doing something so bizarre that it falls outside the boundaries of what the software writers assumed you might be doing. Finally, there's the risk, with such a high degree of isolation, that you may try to implement something either too complex or at least very expensive to implement on the hardware. This could either hamper your design or be an outright barrier to success. So HDL's are things you should use with care, mostly to design relatively mature logic functions. State machine entry works well when your design is simple and has a linear flow. If you think in a sequential way, seeing your logic as a series of states that the system steps through, the FSM entry method will seem logical to you. You could perhaps get quite complex, depending on how big of a state machine you care to visualize. It's great for simple controllers, especially ones with feedback where a state-machine description is fitting and natural. Even relatively complex, closed-loop control systems are good with this kind of system. Nevertheless, it really comes into its own with semi-simple functions, ones that may be more clear with a visual representation, and where the source-code representation of an HDL might make it more opaque what's actually going on. The tools, OTOH, aren't very sophisticated or thought through. Third-party support is rare at best, and you'll probably end up using Xilinx' simulation and verification tools. Furthermore, at some point the design may become very difficult to follow, when you have hundreds of states, and since this method still isolates you from the underlying logic, there's no benefit to displaying a complex design in this way. In many respects, FSM design opens up the same weaknesses as HDLs, although admittedly it's pretty clear if you've got a state machine description that you're not doing anything bleeding-edge, so a great deal of the penalty of abstraction is a nonissue. Nonetheless, state machine synthesis is really for a narrow application range, where you're doing something simple, well-defined, and probably control-system oriented. Schematic entry gives you far more insight into what's happening at a gate-level. If you're a "hardware" person, this will be a natural way to design. You can actually see what the gate implementation is, and this will give you a better immediate feel for timing issues, data paths, and simply what's actually going on in your design. You can design very, very complex logic if you want, and it's easier to optimize the design for the specific device you have. It eliminates a lot of the associated abstraction problems of HDL's, simply because everything happens at a more primitive level. Also, you can instantly see how complex a function is *actually* going to turn out to be, so you can either eliminate or redesign the logic if it turns out to be too expensive. In a sense, you have more flexibility in what you can design, because the tool lets you create logic much more with a specific view to the hardware capabilities of the chip. It may help also to de-mystify what's happening at a hardware level. The big downside of schematic entry is that it's very difficult to modify the design, still harder to port it to a different device. It basically locks you into the device and design you envision at the present. You should also expect a lot of debugging because it doesn't isolate you from implementation-level errors, i.e. your logic may be right, but how you implemented it in the schematic may be faulty, something you can avoid with HDL's. Worse, the verification and simulation capabilities are more limited, and third-party support is essentially nonexistent. Xilinx' tool furthermore has a whole set of frustrating, nonsensical limitations. You should therefore be very confident with your schematic capture capabilities before tackling a design this way. It's best for the more bleeding edge, oddball designs where you aren't overly concerned with design cycle time, and where you don't expect to be changing devices any time soon. Finally, FPGA editor gives you ultimate control, giving you direct access to the physical layout and configuration of the device proper. Obviously, this means you can program any configuration the device is capable of implementing, no matter how bizarre or complex. You can see directly *exactly* what's going on, tweak your fitting down to the last detail, specify precisely what function blocks, connections, etc. implement which piece, etc. The negatives are equally clear-cut, namely, you have *NO*: simulation, verification, portability, error-checking, or third-party support. Experts only need apply, and you'd better know hardware inside and out. Debugging will take a long time, and unless you're really careful, you may smoke a component or 2. So this is a tool to use only if you're an expert and have some freakish, ultra-high-end design where you can't tolerate any sort of compromise whatsoever. Alex Rast arast@qwest.net arast@inficom.comArticle: 32983
arast@inficom.com (Alex Rast) wrote: >... >HDL's excel in complex but well-defined designs, where you know exactly what >... >The downside of HDL's is that the abstraction isolates you very much from the >details of what's going on in the hardware. Typically you don't have ultimate >... >Schematic entry gives you far more insight into what's happening at a >gate-level. If you're a "hardware" person, this will be a natural way to I think this distinction is completely arbitrary. Actually the ONLY difference between HDL and schematic entry is how they are visually presented. You can get an HDL text file which is completely identical to a schematic and that is how you link schematic entry to P&R anyway. You get an EDIF file from your schematic entry tool. Viewlogic's Viewdraw can even generate Verilog from your schematics. You can instantiate gates in Verilog and put constraints etc. which is what the schematic does. IOW, if you want to do gate-level structural entry HDL lets you do it unlike schematic which forces you to only that type of entry. In HDL you have a lot more freedom. You can design complex state machines for control blocks easily and you can be as detailed and low level as you need for datapath blocks. MuzafferArticle: 32984
Thank you for the reply. I'm sure that you could do this with an FPGA - however I'm just a poor embedded systems engineer (;-) ) who is closer to the software than the hardware side of things and this 'little' development is way beyond me! Anyone out there interested in developing a kit or something? Kind Regards, Ivan Vernot "Ulf Samuelsson" <ulf@atmel.dot.com> wrote in message news:2Yf27.3790$5t1.2052@nntpserver.swip.net... > you could do this inside an FPGA! > > > -- > Best regards, > ulf at atmel dot com > The contents of this message is intended to be my private opinion and > may or may not be shared by my employer Atmel Sweden > > "Ivan Vernot" <ivernot@ozemail.com.au> skrev i meddelandet > news:Ezj17.49677$Rr4.38763@ozemail.com.au... > > > > Hello FPGA Gurus, > > I've been trolling the Google archives for this news group looking for a > > Logic Analyzer that I may built as a kit (or buy cheaply) > > > > I came across reference in Oct 1996 for a company - 'ProBoard Circuits' > > which sell a cheap logic analyzer. > > Does anyone have any experience with this Company and have any further > > contact info? > > Can anyone point me in the right direction in being able to find a low > cost > > login analyzer for, relatively' low speed work. > > > > I am looking for something pretty basic - around 8 channels (min) - > perhaps > > 20 MHz max freq. > > Any ideas? > > > > TIA > > Ivan > > > > > > > > > >Article: 32985
On 12 Jul 2001 12:01:04 -0700, Achlys4now@yahoo.com (Achlys) wrote: >Is anyone experiencing block ram failures in Xilinx Virtex-E devices? >We've seen a condition where different bit files will cause hard >failures on a small percentage of the parts. The block rams are >configured as 32-bit wide FIFO's; certain nibbles of the fetched data >seem to be from the previous clock cycle. Locking the block RAM >locations in the design doesn't always help; some devices still fail, >some pass. Re-synthesising the design helps sometimes but not always. >Working boards will fail with new bit files. We've seen the failure on >multiple parts and on multiple designs. > >Is anyone experiencing anything similar or other unexplained failures >with Virtex-E parts? Is this FIFO asynchronous, i.e., are the read and write clocks mutually asynchronous? If so, and if you're meeting static timing, I'd bet on a problem in the control logic. A resynchronization problem isn't going to show up as a static timing error, but it certainly can sink your design. Bob PerlmanArticle: 32986
On 13 Jul 2001 17:36:25 GMT, just as I was about to see how much duct tape you REALLY need to stop a gerbil from exploding, mikeandmax@aol.com (Mikeandmax) distracted me by babbling thusly: >Sounds like you are connecting a couple of 'deadbugs' together - and also >sounds like you've got it pretty close to 'right'. Did you make sure to >adequately decouple and hook up power the the device - when doing a simple >read, not much current consumed, not much noise generated, but writing is a >whole other ballgame, onchip programming supply ramps up and sucks plenty of >current - poor regulation can cause the types of intermittent errors you are >having. I figure you may have tried more than one device also? > > Yes all chips behave the same. Why do I get the feeling you need a small power station hooked up to these things when you want to program them? I have two lengths of kynar wire connecting from the JTAG header to pads which connect directly to the power and ground planes on the processor board. A 7805 powers the entire processor board without dramas. Is this not enough? This thing really sucks THAT much juice?Article: 32988
There is no search path concept in FPGA Express/Compiler. So when you include a verilog file using `include directive you need to make sure that the file is in the same directoy where as the original verilog file exists. There are 3 solutions for this :- (1)If suppose u have a file /a/b/c/test.v which has a `include x.v and if x.v is not there under /a/b/c/ DIRECTORY then just create a link to x.v under /a/b/c/ pointing it to it's original location. link -s <original x.v path>/x.v /a/b/c/x.v (2)Copy x.v to /a/b/c/ directory. (3)Just chnage `include x.v to `include <locattoin to x.v>/x.v (Hard to do !!!) -- Anil Joey Oravec <joey@sun.science.wayne.edu> wrote in message news:<9i5bbh$ias$1@cwis-1.wayne.edu>... > Hi I've had some bad experiences with dc_shell and Xilinx Virtex/E > libraries so I'm trying to use FPGA Expree 3.4 which came with Foundation. > Even though it's Windows based and kind of slow, it's giving way better > results than dc_shell. > > I'm stuck using fe_shell instead of the GUI. It seems to recognize format > by the filename extension, and my designs have the more common .vs, .vg, > .vr extensions. Unlike the GUI, I can specify the format and filename > within fe_shell. > > Only big probelm so far is migrating my scripts. Normally I do a: > > set search_path "$search_path ../../defines" > > in dc_shell so it can find everything that I `include in code. I set this > variable in fe_shell and it seemed to have no effect; when I add files it > was not actually regarding the search path. Is this done differently in > fe_shell than dc_shell?Article: 32989
I just made a byteblasterMV for the acex 1k, and it works:) The resistors are 100ohms and 2.2k. The schematic doesn't show any VCC-GND capacitor across the 74HC244, but i put a 100nF in there anyway. I assume the max3000 is jtag. Try connecting 1k pull-up resistors just in case... Rodo wrote: > > Hi all... > > A friend and I are building this cable to experiment with the MAX3000 series > chips. The datasheet for the cable shows several 100 ohms resistors in > series and 2.2 ohms resistors as pull ups. These 2.2 ohms resistors are very > low to be a pull ups so we called altera to make sure. The tech guy said the > value was right. Not convinced my friend went to ask a professor who > happened to have the evaluation board from altera. After looking at the > schematic for the board the resistors are 2.2K ohms. So, we build the cable > with the 2.2k values. > > The Max+Plus II software detected the cable but it cannot find any device > attached. We have a EPM3032ALC44-10 connected and setup as the target > device. We did supply a 3.3v to all 4 VCC pins in the device and the cable. > We're gonna go back to ask the professor on Monday if we can take his cable > apart and make sure the resistor values are right :-). Does anyone know the > values for the resistors ? Is it 2.2 K or ohms ? > > BTW if we disconnect the cable and check if the device is blank we get a > cable not found error. With the cable connected it says no device or socket > empty. > > Any help/comments are welcome. -- ___ ___ / /\ / /\ / /__\ / /\/\ /__/ / Russell Shaw, B.Eng, M.Eng(Research) /__/\/\/ \ \ / Victoria, Australia, Down-Under \ \/\/ \__\/ \__\/Article: 32990
Dean wrote: > I'm trying to program my first Xilinx device - a 95108. I've created the > jed file, no errors. What I've done is designed a small PCB with a 6-way > header for the JTAG interface (no pull up resistors - do I really need them? > Local FAE says no), and two other headers to pull out all the I/O pins so I > can interface it to the processor board I've added this little board to > (double-sided tape is a wonderful thing). > > I've made sure the connections are right, and am trying to program the > device. I'm using WebPACK v3.3. > > I can apparently erase the device (all entries from the log file): > Have you set the ``override write protect'' tick box when trying to erase the device ? I came across this problem with the original 5V devices where occaisonally you'd get a supposedly new one with its w-prot bit set. This was back in the pre-JTAGProgrammer days of EzTag. Xilinx had to do a hot fix to EZTag to get around the problem - basically adding the override thing above.Article: 32991
Having done some simple projects on Altera EPLDs at college, I am looking to move into this stuff a bit more seriously. I am not going to ask the normal newbie questions, as a quick search of this group covers most things. What I want to know is: Given that the idea in my head now is to do with network switching as a an aim. What Xilinx chip family should I go for? My project might end up on a PCI card or as a stand alone solution. Should I go for Virtex or Spartan? Remember I am starting out, so I need to be able to start small on whatever it is. Should I just start out with the XC4k as on the XESS boards? I want to lear as uch as possible in the next 2 months. Or should I actually o for CPLDs perhaps Coolrunner specifically, since switching is speed critical? Any help is well appreciated. I will most probably be using WebPack. What download cable/development board should I use? Thanks for your interest. Suhaib.Article: 32992
Hello, I'd like to learn how to use and how to program a chipset like FPGAs. Where should I look first ? Could someone help me ? Thanks. Pascal.Article: 32993
Noddy wrote: > > This brings me to my question? Should I rather be > attempting to implement my designs in VHDL instead? Mix it ! A top level schematic, the units below in VHDL, Verilog, etc.. It's amazing, already magic how easy it is to explain what you're doing to somebody else, when you can see all functional units, data flow on one sheet. And, sometimes you see your own design more clearly ;-) when you like to go to HDL only, just replace one sheet to a text page. just my .02 have funArticle: 32994
On Thu, 5 Jul 2001 16:44:13 +0000 (UTC), subodh@best.com (Subodh Nijsure) wrote: >Hello, > >Is the following sequence to download bit file to Xilinx Vertex_E correct? >I am using CPLD which to send bit stream to FPGA. > >Here are the steps I am doing from my Linux driver that downloads the >bitstream to the FPGA. > >1. Hold PROGRAM high wait for 400 us >2. Hold PROGRAM low, monitor the INIT pin, wait for it to go high, this >will indicate FPGA has cleared the memory. > >3. Then hold PROGRAM pin high, CCLK 0, send data bit 0, >4. Then hold PROGRAM pin high, CCLK 1, send data bit 0, >Repeat steps 3 through 4 for entire .bit file. > >Now monitor the DONE pin if its high everything is okay else FPGA download >failed. > >WHat I have observed is after step 2 above if i wait for 100 us and go >back and check the INIT pin it has gone low, I haven't sent any data bits >to FPGA yet. So if INIT pin has gone low (0) should I still continue to >send data? >Also in steps 3 and 4 should one be checking if INIT has gone low or DONE >has gone high? > >/Subodh Nijsure After you pull PROGRAM high, you need a *long* wait before you can begin clocking data. The delay depends on the device... check the data books. JohnArticle: 32995
On Tue, 10 Jul 2001 19:14:29 +0200, Falk Brunner <Falk.Brunner@gmx.de> wrote: >Lionel DORIS schrieb: >> >> I would like to know which is state of all I/Os before the configuration is >> loaded in FPGA. > >They are all tristated. > But beware 'dual use' pins like HDC and LDC! JohnArticle: 32996
arast@inficom.com (Alex Rast) writes: > In article <994923743.528258@turtle.ru.ac.za>, "Noddy" <g9731642@campus.ru.ac. za> wrote: > >Hi, > > > >(using Foundation ISE). This brings me to my question? Should I rather be > >attempting to implement my designs in VHDL instead? My experience with VHDL > >is the Designer's Guide to VHDL! > > Most people, I'm sure, are going to tell you to use HDL's. > > You have 4 basic options: HDL, state machine, schematic, or FPGA editor. These > roughly correspond to decreasing levels of abstraction. May I add a 5th option: JBits. > HDL's > They let you describe your logic in > a source-code-like manner, > > The downside of HDL's is that the abstraction isolates you very much > > > Finally, FPGA editor gives you ultimate control > > The negatives are equally clear-cut, namely, you have *NO*: simulation, > verification, portability, error-checking, or third-party support. Experts > only need apply, and you'd better know hardware inside and out. Debugging will > take a long time, and unless you're really careful, you may smoke a component > or 2. So this is a tool to use only if you're an expert and have some > freakish, ultra-high-end design where you can't tolerate any sort of > compromise whatsoever. JBits also gives you FPGA Editor level control, but using an HDL like source code with all the advantages of replication structures (good for data paths). I managed to get it to work despite being a beginner (previously only 74xx stuff) by simply reading *thoroughly* the Virtex data sheet and the JBits docs, plus a few mails to Xilinx JBits group. The JRoute component allows routing without danger of accidently killing chips. Also runs on any machine with Java support. I develop on Linux, no NT or Solaris. Negatives are: simulation is limited to DeviceSimulator, essentially step the clock through your design, whatching what it does. No protability (only Virtex, and Spartan-II of sizes that also exist in Virtex). And code is fairly verbose (you set everything), and you need to do 100% hand placing (routing is automated). So it is fairly time intensive. -- Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer - Intellectual Property is Intellectual RobberyArticle: 32997
Go to www.bitscope.com They have a kit that includes a logic analyzer and a DSO in one box. I have just started using it and it works great. The software is just adequate, would be nice to have more but it does work. WollyArticle: 32998
I have to disagree. A booth multiplier is more efficient than a regular shift and add. In the 4000 I was able to fit a booth multiplier in the same area as a normal shift and add (which does not use all the inputs in a 4 bit LUT and the recoding just takes two three-LUTs and an inverter). As you know one of our demos is the mandelbrot hardware. You can "unroll" the booth multiplier and pipeline it to save 1/2 the area. Steve "Ray Andraka" <ray@andraka.com> wrote in message news:3B4E8927.BF2AB802@andraka.com... > Booth recoding won't help much in this case. A scaling accumulator > multiplier is a single accumulator with the feedback shifted. It is a > serial by parallel multiplier, that uses a conventional adder. Booth > recoding seeks to reduce the number of partial products by recoding > strings of '1' bits into an equivalent 1, -1 and zeros. The result is > that you can reduce the number of partial products to be combined in an > adder tree, which in turn reduces the size of the tree. Since the > scaling accumulator multiplier is shifting once and adding for N cycles, > you essentially are doing all the partial products regardless of whether > or not they are zero. You could conceivably use Booth recoding in this > case to reduce the number of cycles, but in a practical sense, the added > complexity to the circuit would outweigh the benefit (one could use two > scaling accumulator multipliers, or go to a 2 bits/clock version to get > on average a better speedup for less area and complexity). All he has > to do is subtract the partial product corresponding to the MSB of the > serial input and sign extend the parallel input to handle signed > muliplicands. > > Rob Finch wrote: > > > Try using Booth recoding. > > -- > -Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > >Article: 32999
Noddy wrote: > > Hi, > > As you've guessed from recent posts, I'm very new to using FPGAs (couple of > months). I've been spending my time implementing schematic design entries > (using Foundation ISE). This brings me to my question? Should I rather be > attempting to implement my designs in VHDL instead? My experience with VHDL > is the Designer's Guide to VHDL! If you are getting the job done, don't worry about. My bias is now towards HDLs, but I also started with schematics, and that works fine too. The fact that you asked the question suggests that you have some interest in HDLs. If this is true, you might want to start by writing an HDL testbench for an existing schematic design. --Mike Treseler
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