Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I examined the "Place and Route" and the "Pad" reports. The pad report shows unused as unused. The Place and Route report only describes those instances which were assigned to pin locations. The "Map" report talks about some removed blocks, but describes them as unused VCC blocks. I can't find anything unusual.Article: 34601
Ben Franchuk wrote: > > "Andy Peters > > > > Ben Franchuk wrote: > > > > > > > It's not hidden, Ben, it's just in a different form. The way you know it's > > > > the same is twofold: first, you have a testbench you can run on the > > > > synthesized result, which should produce the same results as your original > > > > code. Second, you have formal verification tools, that can compare the > > > > synthesizer output (gate level verilog, in the case I'm familiar with) with > > > > your original VHDL or verilog code. > > > > > > Since I use free tools I don't have access to the fancy tools. > > > > Further proof of the old adage, "you get what you pay for." > > That must mean all the tools are JUNK. You don't buy the tools you RENT them! That's funny, I'm sure I'd bought the current Altera tool suite. Nial.Article: 34602
Tracy Briscoe wrote: > > I'm trying to generate the CRC in hardware. The problem that I've got is > that every combination that I've tried to generate the CRC, and place it in > a frame, comes back as invalid. I've attached my vhdl testbench, in which I > doing all this. This is all part of a custom hardware project, that will > transmit and receive frames to and from Ethernet. lots of possible bit/byte order problems. check out: http://www.erg.abdn.ac.uk/users/gorry/course/dl-pages/crc.html especially: "Bit Order "The CRC is the only field which is by convention sent most significant bit first. (This is contrary to all header and payload bytes which are sent least significant bit first.) Thus the first bit of the a CRC-32 to be sent is the bit corresponding to X32 and the last, the bit corresponding to X0." Good luck. --Mike TreselerArticle: 34603
Hi, I am Dereck Fernandes, I am a grad student in the University of Massachuetts, Amherst. I working on a Interconnect Test tool for Xilinx Virtex FPGAs. I have a question regarding JBits. 1. Does the routing in the Tile for XC4000 and XCV800 widely differ. I saw a Jbits code for XC4000 which allows you to set the routing: jbits.set(row,col,Y.HORIZ_SINGLE1,Y.ON) Is this the same in XCV 800. 2. I am basically trying to understand how the routing looks in XCV800, In the databook for XC4000 you have a figure that gives detail of the Programmable Interconnect (Figure 27 Page 6-30). Do you have a similiar page for XCV 800 or is it the same. 3. I need to know how many single,double,long lines are present in each tile. Can you help me in this. Thank you, Dereck FernandesArticle: 34605
1. Is the lastest version of JBits 2.0.1 2. Does the lastest version or the version above support programming of the Pads, does it have IOB support. I require this to test the CLBS on the Periphery. My advisor did not recommend the use of the latest version of Jbits which I had contacted you for instead he wants to use the JBits 2.0.1. Please let me know if its a good idea. Incase the new version has fixed some critical bugs. 3. I guess JBits can be used only with a existing bitstream. Now we don't have Virtex hardware with us. Can you tell me where can I get a input bitstream for XCV 800 and other Virtex parts. I need this to test my tool which is essentially a Interconnect Test tool. Thank you, Dereck FernandesArticle: 34606
"David Wright" <dwright@srtorque.com> writes: > The "free" Xilinix Webpack should be classified as a Demo and not a real > system to do even realistic small designs. You get what you pay for. Naturally the free package provides less functionality than the expensive package; how can you rationally expect otherwise? Calling it a "con game" seems entirely uncalled for; the features and limitations of WebPack are plainly described on the web site. I've found it to be perfectly usable for a design with a 32-bit RISC core, memory, UART, Ethernet, and timers. I did my simulation using Savant.Article: 34607
Eric, Could you describe you method for running savant with the Web Pack? I would be interested. Also how about Symphony EDA? I agree that Web Pack is able to do a lot. I was able to do a Spartan II 150 with it. Only the simulation was Verrrrrrrrrrrrrry slow. But, however, at least it ran the simulation. Which is better then saying: "Sorry design too large to simulate" like some demos do and exit the simulation. Also the synthesis and place and route tools are certainly worth the effort to download. I was able to do quite a lot with this tool. Actually produced some real results. Thanks Dave Colson Eric Smith wrote: > "David Wright" <dwright@srtorque.com> writes: > > The "free" Xilinix Webpack should be classified as a Demo and not a real > > system to do even realistic small designs. > > You get what you pay for. Naturally the free package provides less > functionality than the expensive package; how can you rationally expect > otherwise? Calling it a "con game" seems entirely uncalled for; the > features and limitations of WebPack are plainly described on the web site. > > I've found it to be perfectly usable for a design with a 32-bit RISC > core, memory, UART, Ethernet, and timers. I did my simulation using > Savant.Article: 34608
On Wed, 29 Aug 2001 22:22:26 GMT, arast@inficom.com (Alex Rast) wrote: >In article <3b8b9869.9160001@news.compuserve.com>, 101551.3434@compuserve.com (Mark Taylor) wrote: >>On Mon, 27 Aug 2001 20:09:17 GMT, arast@inficom.com (Alex Rast) wrote: >> >>>In article <3b86ed56.46990212@news.compuserve.com>, 101551.3434@compuserve.com >> (Mark Taylor) wrote: >>>>On Fri, 24 Aug 2001 00:19:48 GMT, arast@inficom.com (Alex Rast) wrote: >>>> >>>>>This is one I think I've done before, so I probably just need my memory >>>>>jogged. I'm sure it's something that happens, and that you need, all the >> time. >>>>> >>>>>I've defined a hard macro, call it custommacro.nmc. .... Now, at least one >> of the nets connects to an >>>>>external pin and an internal route. One common example, for instance, is >> CLK. >>>>>You want the signal to be common to the internal CLB's of the macro and to >>>>>connect to external routes (in the case of CLK, to the global clock net). >>>> >>>>As far as I know, nets could never be included in hard macros. >>>>(despite documentation suggesting otherwise, right back to before EPIC) >>> >>>No, I have no problem including a net in a macro. What I have difficulty doing >>>is routing an external net *to* the macro's internal net. >>> >>>>Just use the hard macro to configure slices/CLBs or whatever, >>>>then embed the macro within a soft macro >.. >>>I don't think this would work, for 2 reasons. First, I *have* to have a >>>specific routing within the hard macro (indeed, the routing itself is a key >>>part of the design), so I can't afford to let the software take care of any >>>routing at the hardware level. Second, a lot of the things we're doing are >>>functions you simply can't enter properly in Schematic Editor... >>Get rid of any general purpose routing within your hard macro. >>Keep all interconnections within a CLB. (These doesn't really count as nets at >>a low level) > >I don't think I can do that because some of the nets are both general-purpose >to the design and special-purpose to the macro. In other words, we have >logic-to-logic connections within the macro that also connect to nets going >between macros. And the connections within the macro are routing-sensitive. > >>Ensure the number of macro pins is enough to complete all needed routing. > >I *hope* I've done that, except if you mean that the number of macro pins must >include a separate pin for *each* separate input of a high-fanout net in which >case it's a pretty hopeless task. > >>Now you will have a hard macro, with perhaps somewhat more pins than you had >>before. >>When you instantiate this macro you will be able to complete ALL routing. >>(there won't be any strange nets for the software to complain about.) >>This approach has worked for me in the past. >>Bear in mind that the router is usually pretty good. > >IME it actually sucks rather than being pretty good, because it fails to >consider routing strategies like multi-drop nets or symmetric "bank-shot" nets >among other things. Again, it seems to work via a "one resource, one >connection" strategy. Again, for giggles, I experimented with a program-routed >net against my hand-routed net for the same design. I tested it with a design >occupying 6 CLB's. My manually routed version created a symmetrical route >using only the routing resources adjacent to the CLB's in use, while the >program's version implemented the routing in an asymmetric net over resources >adjacent to CLB's in a 12-row 7-column (84-CLB) block centered on the 6. > >>It's just the mapping & placement that sometimes needs working on. >>The mapping & placement is totally defined by the given approach, so >>theres nothing much to foul up on afterwards. (unlike the M1 software) >>If you don't like the routing around an instance of the macro you can still >>change it. >>The routing will generally be optimal, unless you have RAMs >>within your macro. > >Given the results of my little test, it was clearly not optimal - and the >design I tested it on didn't have RAMs. > >> You can pretend (with very great care) that the RAMS are >>LUTs , which will allow excellent routing. You will then have to patch the RAMS >>back in later (perhaps using fpga_editor , or XDL if you have a large number >>of instances.) >>Note that XST (VHDL) sometimes doesn't keep RLOCS. >>This is a bug that I have recently complained about. >>If you are not using XST , you should have no problems. > >I should make it very clear that the design I have has to be very carefully >fitted together like a jigsaw puzzle. I have to design the *shape* and exact >configuration of the routing resources for each macro I have, so that I won't >be stymied by either lack of an available specific resource or inability to >abut a macro against another because of space versus shape restrictions in the >CLB, in the overall design. > >Does any of this make any sense or am I bringing up needless issues? > >Alex Rast >arast@inficom.com >arast@qwest.net The technique which I have mentioned works. However, I have just proved us both wrong. The ISE 3.x Fpga_Editor seems to be much improved. I tried creating a macro with an internal route. I instanced that and added to the net . It worked. I added an undriven clock net to the macro, calling it something else. I instanced that. I added a global clock buffer. I added the global clock buffer output to the 2nd net. It worked. Note that all pins used within the macro were entered as macro pins. So you must be doing something wrong, such as not entering all your pins. Or perhaps you are attempting to work with Locked routing? (might be better to unlock it?(just guessing here)) I am assuming that you are using a moderately up-to-date version of the Xilinx software? If not why not? I am assuming yiou are using something similar to a Virtex device? (eg Spartan2 or VirtexE ?) I'm still fairly sure the Xilinx router is good, when one wishes to have low net delays. The independent buffering gives good high speed lines even where fanouts are large. The clock routing is nicely fast. You could try giving me a job, if you have further problems.. Mark Taylor. Mark_Taylor_Chess@compuserve.comArticle: 34609
Rick Filipkiewicz wrote: > The *second* key to sane HDL design is to choose a tool that works purely from > the command line & uses no registry settings. I would put it even more strongly > than that - if a tool does do this sort of thing then it should be rejected. Env > variables you can over-ride in the makefile. In other words, use Unix-based tools, and the wonderful symbolic link, to go between v8.0 and v8.1 of the tools. The move towards Windows-based tools is a bad one, and hopefully EDA vendors will wake up and realize that fact. We have cheap hardware, and a free OS (Linux) that works, so support it, already! -andyArticle: 34610
> > The *second* key to sane HDL design is to choose a tool that works purely from > > the command line & uses no registry settings. I would put it even more strongly > > than that - if a tool does do this sort of thing then it should be rejected. Env > > variables you can over-ride in the makefile. > > In other words, use Unix-based tools, and the wonderful symbolic link, > to go between v8.0 and v8.1 of the tools. > > The move towards Windows-based tools is a bad one, and hopefully EDA > vendors will wake up and realize that fact. We have cheap hardware, and > a free OS (Linux) that works, so support it, already! Yes, but no corporate environments I've ever worked in use Linux.Article: 34611
The SRL16's are 16 bit serial-serial out, but you can dynamically address them to access more than one bit per shift clock without actually shifting them. If you can provide a multiple of your shift clock, you might be able to take advantage of that feature. Also, if you are not using the BRAMs otherwise, thsoe can be utilized. Tim wrote: > "Michael Boehnel" <boehnel@iti.tu-graz.ac.at> wrote > > I want to implement several big shift-registers with parallel load > > (parallel to serial converter) in a Virtex-E. Beside these SRs I also > > want to implement SRs with serial input and (big) parallel output. > > > > The number of CLB FFs in the FPGA are limited (Rows x Columns x 4). > > > > Is there a way to implement one of these SRs (parallel load or output!) > > without using the CLBs FF's. > > The Xilinx SRLs give you a x16 density gain. They are serial-in/serial-out > so you need to play with the algorithm. > > BRAMs can give you parallel load (x32) and serial out (x1) by using the > dual-port feature. > > > Can one of the synthesis tools manage this for me automatically(FPGA > > Express, Synplify, ..)? > > Synplify can. And probably FGPA Express - check with Synopsys. > For funky stuff, instantiation is probably less trouble to you. -- -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: 34612
Dave Colson <dscolson@rcn.com> writes: > Could you describe you method for running savant with the Web Pack? > I would be interested. I just ran Savant normally. There's no integration with WebPack.Article: 34613
"Austin Franklin" <austin@darkr99oom.com> writes: > Yes, but no corporate environments I've ever worked in use Linux. Other than my own employer, nearly every company I've had contact with here in Silicon Valley that does large ASIC designs is now using Linux for their simulation farms, since it's so much more cost-effective than Windows. And I'm not just talking about the purchase cost, although for a large farm that may actually be a consideration. In general, the Linux-based simulation farms seem to require much less administrative overhead than the Windows ones they replaced.Article: 34614
"Dereck" <dereckaf@yahoo.com> wrote in message news:ee722b3.-1@WebX.sUN8CHnE... > Hi, > I am Dereck Fernandes, I am a grad student in the University of > Massachuetts, Amherst. I working on a Interconnect Test tool for Xilinx > Virtex FPGAs. > > I have a question regarding JBits. > > 1. Does the routing in the Tile for XC4000 and XCV800 widely differ. I > saw a Jbits code for XC4000 which allows you to set the routing: > jbits.set(row,col,Y.HORIZ_SINGLE1,Y.ON) > Is this the same in XCV 800. Virtex is much simpler and much more powerful. > 2. I am basically trying to understand how the routing looks in XCV800, In > the databook for XC4000 you have a figure that gives detail of the > Programmable Interconnect (Figure 27 Page 6-30). > Do you have a similiar page for XCV 800 or is it the same. Write to jbits@xilinx.com > 3. I need to know how many single,double,long lines are present in each > tile. The basics are in the data sheet and visible in FPGA_editor. More info comes with JBits.Article: 34615
Great beer cooler, but I think he should make some use of all that wasted heat - maybe a combo beer cooler, hot dog roaster ... Peter Seed wrote: > > Even better > > www.asciimation.co.nz\beer > > Not sure what its got to do with embedded though... > > Russell Shaw wrote in message <3B7B401E.E90A0168@iprimus.com.au>... > >http://www.asciimation.co.nzArticle: 34616
Many laptops have software that's probing the parallel port for things like external cd drives etc. Try disabling them. G E Geiger wrote: > > Has anyone tried the Xilinx download cable "Parallel III" on a Win ME > machine? > > I have installed the entire tool chain on my Win ME laptop and I can > get all parts working except this cable. The Xilinx hotline said that > it was probably "noise" on the cable since this is a 900MHz machine > but that ME would not actually be supported until release 4.1 of the > Alliance tools. > > The cable works fine in the lab on a slower PC running Win 98 SE. > > Could MS have actually messed up a parallel port going from 98 to ME? > > On Tue, 14 Aug 2001 13:50:01 GMT, "Paul Teagle" > <pteagle@bigpond.net.au> wrote: > > >I had a ME related problem a while ago (look back for some archive > >material - Xilinx solution 9253 was most appropriate). > > > >Basically, it was a problem with the path. Be careful how you attempt to > >modify the autoexec.bat file. You have to use the system utilities to > >modifiy, not just a text editor on the autoexec.bat files. There's registry > >issues involved. > > > >I've now got a problem with the ModelSim package not finding the design. Oh > >well... -- ___ ___ / /\ / /\ / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ /__/ / Victoria, Australia, Down-Under /__/\/\/ \ \ / http://home.iprimus.com.au/rjshaw \ \/\/ \__\/ \__\/Article: 34617
Hello, I have been working on this project of mine using Altera's AHDL tools andnow when I all the code is done, i wanted to simulate it to see what i getas my result. I don't why i am getting 2 different results :- 1) when i use Functional SNF extractor I get my output exactly as i wanted. And after simulating thru functional snf i simulate it again without it with just normal simulation features (compiler netlist extractor, database builder, logic synth, partitioner, fitter (not quartus fitting), assembler) to get a TFF file which i include in a dll. this thing work fine but i when i chk for my clock output on the test pin i don't get any signal ... why is that?? 2) when i use Timing SNF extractor i don't get my ouput correctly... like some are delayed and thus throws out wrong information on simulation. Now is there any way so that i don't get all these problems with timing....i'm using FLEX 8000 series chip Waiting for ur reply as soon as possible.... if u need to look at the code please email me back....thanksArticle: 34619
I have always tried to stick to sync designs. However lately I have ran into a problem. While designing some isa cards I read somewhere that I did not need to use BALE to latch my address lines. Is this acceptable? Also I am decoding using a state machine in a FPGA with Sysclk as the clock for transitions in my state machine. Last week I changed CPU and the new CPU card does not drive Sysclk. Now my boards do not work. I called the board designer and de says that sysclk now a days is not sync with the I/O signals anyway? Who do i believe? Is async acceptable? Are the address lines stable so BALE is not nescessary? Any comments suggestions? Xilinx foundation users is it possible to take the VHDL created by the state diagram editor and make the state machine async and dependant on the input signal transitions to go from one state to another? Steven Collins Macha International, Inc. 713-723-5040x13 scollins@macha.comArticle: 34620
Some time ago I received the CD titled: Device Update Foundation Series 3.3i (Contains Virtex-II Device Libraries and Service Pack 6). I can't figure out how to install it on my Solaris machine. There is nothing about Solaris in the Readme.txt file. There is only a Setup.exe Windows executable. How do I load the libraries under Solaris? I'm primarily inter ested in the Virtex-II device libraries since I have already in stalled SP8 from the Xilinx Web site. Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 34621
Hi, I am using the Spartan XCS10XL just as a clock signal (using as an encode signal for an A/D). Anyway, I'm reading the clock signal into the FPGA on a global clock buffer, put it into a toggle to halve the frequency(from 50 to 25MHz), and then output it again on a standard output pad. However, at 25MHz I would expect the signal from the toggle to be pretty close to square, but my signal still looks very wobbly. Can anyone give any suggestions? AdrianArticle: 34622
David Wright escribió: > > The "free" Xilinix Webpack should be classified as a Demo and not a real > system to do even realistic small designs. > > By the time you install the design and even a small test vector, you easily > exceed the 500-line ModelSim Starter Design Limit. There are even > limitations on Test Bench and probably other portions of the package. I agree with the Bencher limitations: are stupid, because you can generate two or three vectors and then use notepad to copy-paste-modify. But I don't agree with the ModelSim (HDL only simulator) 500-line limitation: is more than enough to test modules separately, and there is no slow-down if you use *.do files. Please, check "http://www.dte.eis.uva.es/OpenProjects/OpenDSP/index.htm" and see how a complete DSP has been synthetized and simulated using WebPack. > Xilinx needs to stop misleading its customers and tell them what they really > need to know: At least, it's (now) better than Altera's free tools. Enjoy, Santiago.Article: 34623
comp.arch.embedded is probably the best place for this question. AFAIK. "DIVERSEG" <diverseg@aol.com> wrote in message news:20010831014900.26248.00004289@mb-fy.aol.com... > > I have always tried to stick to sync designs. > However lately I have ran into a problem. > While designing some isa cards I read somewhere that I did not need to use BALE > to latch my address lines. > > Is this acceptable? > > Also I am decoding using a state machine in a FPGA with Sysclk as the clock for > transitions in my state machine. > > Last week I changed CPU and the new CPU card does not drive Sysclk. > Now my boards do not work. I called the board designer and de says that sysclk > now a days is not sync with the I/O signals anyway? > > Who do i believe? > > Is async acceptable? > > Are the address lines stable so BALE is not nescessary? > > Any comments suggestions? > > > Xilinx foundation users is it possible to take the VHDL created by the state > diagram editor and make the state machine async and dependant on the input > signal transitions to go from one state to another? > > > Steven Collins > Macha International, Inc. > 713-723-5040x13 > scollins@macha.com >Article: 34624
A correction: I subsequently found problems with respect to internal macro nets. 1) If a net is deleted there is a problem. 2) If multiple instantiations of a macro are made then it might be tough to connect a common clock line. So I can only refer you to what I originally said. DON'T USE INTERNAL MACRO NETS. ENSURE YOU HAVE INCLUDED ALL MACRO PINS. I suspect you may have been using the P&R tools at the default settings: "brain-dead". Turn up the level to "decent". Ensure you have the delay - based clean up pass selected. I have in the past only used hard macros when there have been mapping deficiencies. (ie 4000X series) I haven't yet found any need to use hard macros for Spartan2 (Virtex), because the primitives available map well to the capabilities of the CLBs. You could try giving me a job, if you have further problems.. Mark Taylor. Mark_Taylor_Chess@compuserve.com
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z