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
I'll be doing designs with multiple large RPMs too. Are the netlists hierarchial in 5.1? Efficient handling of hand-routed RPMs in a hierarchial netlist is what i consider to be *the* most important feature. It should be easy to build low-level RPMs and link them together to make larger RPMs, until you've done the whole project from the bottom up. In the end, your whole project is an RPM, which you could re-use as a library component. It's not hard to see that anyone could be building mega-chip designs from these components in just a few minutes. It's this sort of capability i'd aim for in an open source tool. lass wrote: > > Ray, > > This is planned to be fixed in our 5.2i release. We might be able to create a tactical > patch for you before that, but it sounds like you are not using 5.1i and since no other > customers have run into this problem, the current plan is to wait until 5.2i (Feb). > > Steve > > Ray Andraka wrote: > > > I wish that were the case. This is something that broke in 5.1 that causes map > > to take 25+ hours to complete where it completed in less than 2 hours on a > > machine with half the speed and memory (and paging like crazy on that machine) > > using 4.2...Article: 48551
I've delivered a prototype based on large cpld's (xc95288xl), and now the customer is asking about the costs of a production version. I suspect that a relatively modest fpga would also work well for this application - think 85MHz clocks, multiple 32 bit wide data paths, interface to a modest frame store. So the question is, at what sort of production volume should I be asking about ASIC's ? The last time I investigated this, nobody seemed to think that it was worth considering for less than 10k+ units/per annum, plus the fact that it would take 6 - 9 months to get working silicon. Since then, the impression I have gained is that fpga's are even more competitive, together with the usual advantages of being 'soft' - but what do you find in practise ? Any info or pointers welcome regards, DaveArticle: 48552
Hi Huijun, Two problems with your request: 1) The Xilinx core is delivered as a device-specific black-box macro. The is no HDL, Verilog or otherwise to "start with" 2) The Xilinx core is a commercial device, and costs -money-. People could go to jail if they sent you a copy. There used to be a perfectly acceptable PCI core on the web. But the person who wrote it got tired of people complaining about it, so took it down. SH7 On Fri, 18 Oct 2002 13:24:17 -0400, "huijun xie" <hxie168@townisp.com> wrote: >Kevin > >I am new in PCI and PCIX design. I am going to design my own PCIX core, and >this core has to be backward compatible with PCI. Right now I am thinking to >start with PCI CORE and then upgrade to PCIX, I don't know how much work it >is going to be. I am using Verilog, and am very intersted in starting with >some kind of PCI core. Could you please kindly send the Xilinx verilog PCI >core to me? my email address is: hxie168@hotmail.com > >You guys are great! I have learned a lot just by reading your messages. I >appreciate your help. > >Best Regards! > >Huijun >Article: 48553
"Klemen" <nec4b@email.si> schrieb im Newsbeitrag news:aou0m4$6fq$1@planja.arnes.si... > Recently i got the insight spartan II demo board and xilinx webpack, but i > can't get the board to work. Xilinx iMPACT doesn't recognize it. The board > is connected with the computer through jtag cable. I tried all sorts of > combinations with the jumpers on the board, but no matter what i do it just > doesn't work. I'm a beginner with fpga and i'm getting very frustrated with > not finding the mistake, please help. Check the voltage on the board. There are two regulators, als well as two testpins for 3.3 and 2.5V. Check the connection from the JTAG cable to the board. DO you connect to the right pins? Nothing mixed up? The cable comes with two flying leads connectors, make sure you use the right on and hav connected to the right pins on the cable (usually you can mix it up, unless you use brute force) Have you installed the software propperly? Sometimes something goes wrong with the multilinx parallel port driver installation. -- MfG FalkArticle: 48554
Spam Hater,
Before Xilinx got into the IP business to protect its design wins, they
used have PCI interface reference designs (I personally won't call it a
PCI IP core because they backend interface isn't too general purpose.)
written in Verilog, VHDL, and ABEL.
The VHDL and ABEL versions are still available even today from Xilinx's
ftp site.
ftp://ftp.xilinx.com/pub/applications/pci/
Anyhow, just for curiosity, who used to distribute the PCI IP
core you are talking about, and when was it taken down?
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Spam Hater wrote:
>
> Hi Huijun,
>
> Two problems with your request:
>
> 1) The Xilinx core is delivered as a device-specific black-box macro.
> The is no HDL, Verilog or otherwise to "start with"
>
> 2) The Xilinx core is a commercial device, and costs -money-. People
> could go to jail if they sent you a copy.
>
> There used to be a perfectly acceptable PCI core on the web. But the
> person who wrote it got tired of people complaining about it, so took
> it down.
>
> SH7
>
Article: 48555On Fri, 18 Oct 2002 21:36:35 GMT, "Steve Casselman" <sc@vcc.com> wrote: >I've been keeping track of just the raw number of posts to both >comp.arch.fpga and comp.dsp and in the last 2 months arch.comp.fpga has had >more posts per day. I'm wondering if fpgas are going more mainstream or dsps >are just so well known that people don't ask as many questions... > >Any thoughts??? > >Steve > Steve, seems to me that many (most?) of the posts here relate to problem with/bitches about the tools. The DSP folks seem to have less of that sort of trouble. JohnArticle: 48556
Rick Filipkiewicz <rick@algor.co.uk> writes: > o If you want to use 3V `QuickSwitches' be aware that they come in 2 > flavours - "clamping" and non-"clamping". I haven't heard of these "non-clamping" Quickswitches. Are there 3.3V powered non-clamping equivalents of the PI5C3125 or PI5C3245? I need to switch four 3.3V PCI signals, and am currently using a 5V Quickswitch because I thought the 3.3V Quickswitch would clamping the signals to substantially below the Vdd of the switch. I can't figure out from the data sheet whether the PI3B3125 and PI3B3245 will clamp the signals to a lower voltage or not. What's the relevant specification? Vik? And can unused switches be left open? Or should I ground one or both sides? Thanks for any advice! EricArticle: 48557
Eric Smith wrote: > Rick Filipkiewicz <rick@algor.co.uk> writes: > > o If you want to use 3V `QuickSwitches' be aware that they come in 2 > > flavours - "clamping" and non-"clamping". > > I haven't heard of these "non-clamping" Quickswitches. Are there 3.3V > powered non-clamping equivalents of the PI5C3125 or PI5C3245? I need to > switch four 3.3V PCI signals, and am currently using a 5V Quickswitch > because I thought the 3.3V Quickswitch would clamping the signals to > substantially below the Vdd of the switch. I can't figure out from > the data sheet whether the PI3B3125 and PI3B3245 will clamp the signals > to a lower voltage or not. What's the relevant specification? Vik? > > And can unused switches be left open? Or should I ground one or both > sides? > > Thanks for any advice! > Eric There are 2 Pericom ranges of `pass transistors in a box' powered from 3.3V. They start with either PI3B or PI3C. PI3C: Uses NMOS transistors with a charge pump on the gate. VCC range 2.5-3.3V. The output can go up to VCC+0.5V. PI3B: Uses a CMOS pair. The output can go to VCC but not beyond. So either use PI3B or PI3C + 2.8V supply. IIRC IDT, who bought Quality Semi - inventors of QS parts, also have a similar pair of component ranges but I can't remember their names just now.Article: 48558
Hi, A 6502 compatible core is available at http://www.birdcomputer.ca/Cores/bc_6502.html Small and Fast. RobArticle: 48559
hello, I use the modelsim version 5.6d on linux red hat 7.1. ( the modesim is a logic simulater for the lsi design. ) the simulation stops at the same point with the following message: ----- Signal 25 caught in vish vish exceeded user specified file size limit. Check your shell ulimit or limit settings. ** Fatal: Trouble with User Interface. ** Fatal: vsim is exiting with code 218. SIGPIPE seen! -- then, I have sent to request to resolve this problem to Modeltech with the above message, and returned the following message: -- Linux has the ability to limit the amount of memory that can be used by a process, the maximum size of a file, etc. Modelsim is hitting one of these limits. The OS generates a fault, which causes modelsim to shut down. As the error suggests, take a look at the man page for limit and ulimit. You need to determine what type of limit you have set too low, and increase it using the limit or ulimit OS commands. -- I should change something for linux settings. could you please let me know, what points should I change to fix this problem ? best regards, Kiyoshi TakagiArticle: 48560
Rob Finch wrote: > > Hi, > > A 6502 compatible core is available at > http://www.birdcomputer.ca/Cores/bc_6502.html > Small and Fast. ? It might pay to put some numbers on 'Small' and 'Fast', as well as indicate candidate FPGAs it is tested on / optimised for ? -jgArticle: 48561
On Sun, 20 Oct 2002 13:52:38 +0100, Rick Filipkiewicz <rick@algor.co.uk> wrote: > > >Allan Herriman wrote: > >> On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain <ken@synplicity.com> >> wrote: >> >> >Thanks! Actually there are several of the hotline folks that read the >> >newsgroup, but we limit the number of posters. >> >> Ah, good. I'd like to know what you are doing about the SRL16 >> inference rule change between 7.0 and 7.1. We have a number of >> designs here that break in 7.1 and 7.2 because Synplify Pro is >> inappropriately changing FF into SRL16E. >> >> Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted >> to SRL16E. SRL16E don't work at 350MHz (in Virtex2). >> >> Problem 2 (still outstanding) Some FF with async reset get converted >> to SRL16E. SRL16E don't have an async reset input, so this is a >> functional change. >> (It's that old problem of Synplify trying to be too clever about the >> meaning of GSR when the startup block is present. If an FPGA has an >> external reset input (connected to the startup block) then it is *not* >> correct to assume that GSR is only active during configuration.) >> >> Problem 3 (still outstanding) Some FF that were in IOBs get converted >> to SRL16E. This breaks the I/O timing on the part. >> >> Problem 3 is actually the worst one for us, since most of the designs >> infer I/O FF. >> > >Does `syn_useiobffs' stop it inferring SRL16Es ? If not this is a killer >bug and mucho thanks for the warning as I was just about to make the move >from 7.0.2 -> 7.2. Haven't tried that one. This is legacy code that doesn't have many tool specific attributes. In general, I don't like littering my code with attributes just to get reasonable behaviour from the synthesiser, particularly when earlier versions of the same synthesiser did the right thing. But I guess it all hinges on the meaning of "reasonable" ... As we saw with the tristate buffer push through bug, tool vendors can have a rather odd view of what customers want from their tools. >> >> I rather liked the 6.x rule that only allowed an RTL FF to be >> converted to SRL16E when the FF was coded without an async reset or >> set. >> > >In fact I can't see how Synplify can legally infer an SRL16(+/-E) for an FF >with any sort of set/reset sync or async since the Xilinx primitive doesn't >have a reset pin!. IIRC this was actually broken in 6.0beta and I had a I2C >module shift reg with sync. clear inferred as an SRL16. Got fixed in 6.1 I >think. Well, it seems to be broken again. Regards, Allan.Article: 48562
Hi, I am using an FPGA to access a Compact Flash card. How can I find out the files and directory structures of the files in CF card? I wrote in some binary files with a Win-XP compatible card reader. What kind of knowledge do I need to read? Thanks.Article: 48563
Hello all,
here's an appendix to the parallel port connection discussion...
maybe it's useful for somebody else, too.
my starting point:
>> ...for configuration purposes, I have to connect a PC to my FPGA
>> board. It's a Spartan2 device. PC must write, not read.
>> ...
Peter's hints:
> ...you will probably need a RC filter
> followed by a Schmitt trigger to clean up the strobe (=config
> clock) at the FPGA end
> of the cable. You dont need to connect to the FPGA's BUSY since
> ...
This is what finally works for me:
1) Busy is cleared after configuration ( BUSY <= '0' )
2) /ACK is connected to /STROBE on the connector
this is required by the other side (generic vxWorks driver)
3) PaperEnd is connected to /GND on the connector
this is required by the other side (generic vxWorks driver)
4) /STROBE is directly connected to the FPGA,
there's no RC filter.
Instead, the signal is cleaned inside the FPGA
(piped through a few registers with async reset).
My first approach was without ACK and PaperEnd signals,
and it worked fine while the other end was run by a Linux machine.
But it failed if vxworks was driving the remote side.
Only after connecting ACK and PaperEnd like described, data can be
transmitted.
Bernhard
--
before sending to the above email-address:
replace deadspam by foerstergroup and .com by .de
Article: 48564Hi All, I tried to download the free Webpack software from Xilinx website. Whatever I did, I could not download the single file (170 MB) beyond 26%. I tried two download managers, GetRight and Gozilla, to no avail. The server is always busy with something else. Is there a way around? I do have a fast connection to the net. Thanks for any suggestions. Thanks and regards, Murali.Article: 48565
On Mon, 21 Oct 2002 14:16:57 +0800, "Calvin Klein" <Far@East.Design> wrote: >Hi, > >I am using an FPGA to access a Compact Flash card. How can I find out >the files and directory structures of the files in CF card? I wrote in some >binary >files with a Win-XP compatible card reader. What kind of knowledge do I >need to read? Thanks. > Compact flash cards are usually formatted for either FAT16 or FAT32. Most devices only support FAT16 but newer MS OSs support FAT32 for large flash cards. Linux has FAT16/32 file system drivers from which you can see the file system structure and even get some code to decode them. Muzaffer Kal http://www.dspia.com ASIC/FPGA design/verification consulting specializing in DSP algorithm implementationsArticle: 48566
Hi! > I should change something for linux settings. could you please let me > know, what points should I change to fix this problem ? First of all you should _read_ the man pages of limit and ulimit, as the message suggests. man limit man ulimit man bash (and seek for "ulimit") Bye HansiArticle: 48567
> It might pay to put some numbers on 'Small' and 'Fast', as > well as indicate candidate FPGAs it is tested on / optimised for ? > Documentation, documentation, grumble, grumble. People are always asking for more documentation.... (I'm incentive challenged). Small: I have built a real system in a SpartanII-5 200k part (the slowest speed grade) using Xilinx tools. The cpu core consumed less than 700 LUTs and no BRAM resources. The core size could also be trimmed further by not using high order address lines and uneeded control signals. This will easily fit into the smallest SpartanII part with loads of room to spare. I have built a complete system including cpu, video / audio controller, keyboard / mouse controller, timer, and uart in a 200k FPGA and I'm wondering what to do with the other half of the FPGA that's left over... Fast: I was able to get the cpu operating at 40MHz, which is almost identical to the performance predicted by PAR. Platform Independent: The core is not optimized for any FPGA in general although it was developed using an Xilinx part, and is plain Verilog code with no vendor specific enhancements. As such it should be portable to many implementations including ASIC I think (but I don't know enough). I also synthesized a version of the core using Altera's toolset. While I did not build an actual system (because I don't have an Altera development board) I got similar results. The tools predicted an clock frequency of 44MHz (slightly faster than Xilinx), and a size of about 1300 LCELLs ? (LUTs ?) I was unable to figure out why there was a significant difference in the number of LUTs for the Altera part, but maybe I was comparing apples to oranges. In any case I was not going to create a vendor specific core anyway. The core is also not floorplanned and was automatically placed and routed. I am hesitant to give out numbers because too often they are taken as absolutes. The size and performance of the core could vary significantly depending on the application. With a little bit of work, I could make the core either smaller or faster. RobArticle: 48568
There are 8 frames in the beginning that only have the main clock buffers and the DLLs in the frames the middle portion is 0's. Most of the frames in the V1 devices have lots of ones and zeros. If you look at a bit file in a binary editor you'll see this. I just ran my software for the V2 and those devices do have 0's for a blank configuration. Also they have all the configuration bits for a look up table in the same frame. Steve "Neil Franklin" <neil@franklin.ch.remove> wrote in message news:6uk7ke34a1.fsf@chonsp.franklin.ch... > "Steve Casselman" <sc@vcc.com> writes: > > > > Unused bits are set to zero, which compress really well. ;-) > > > > This is not ture. If you go into the fpga editor and create a blank part you > > will see lots of ones and zeros. > > neil@chonsp 16:09:11 ~> vd -er 0/0 null300.bit > Col: 0, Row: 0 CLB: > 0 1 2 3 4 frame > 012345678901234567890123456789012345678901234567 addr > .------------------------------------------------ > 0|110111110001100011111011110111110001100011111011 > 1|100001000101011010000001100000010110111000100001 > 2|111111111111111110000000000000011111111111111111 > 3|111111111111111100100000000001001111111111111111 > 4|000000000100001000000000000000000010100000000000 > 5|000000000000000000000000000000000000000000000000 > 6|000000000000000000000000000000000000000000000000 > 7|000000000000000000000000000000000000000000000000 > 8|000000000000000000000000000000000000000000000000 > 9|000000000000000000000000000000000000000000000000 > 10|000000000000000000000000000000000000000000000000 > 11|000000000000000000000000000000000000000000000000 > 12|000000000000000000000000000000000000000000000000 > 13|000000000000000000000000000000000000000000000000 > 14|111111111111111111111111111111111111111111111111 > 15|100011100011100011100011100011100011100011100011 > 16|111111111111111111111111111111111111111111111111 > 17|111111111111111111111111111111111111111111111111 > bit addr > > > > What is ture is that the if a lot of the > > chip is not used there is a repeating pattern that is the same for each > > unused tile and so a low utillization design gives better compression > > results. For example if you just have one input and one output and one wire > > inbetween in a V1000 it compress about 100x.. > > Empty XCV300: > -r--r--r-- 1 neil franklin 219047 Sep 27 2001 null300.bit > -r--r--r-- 1 neil franklin 3794 Sep 27 2001 null300.bit.gz > > About 1/4 full XCV300: > -rw-r--r-- 1 neil franklin 219047 Oct 16 00:34 pdp10.bit > -rw-r--r-- 1 neil franklin 21241 Oct 16 00:34 pdp10.bit.gz > > > -- > Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/ > Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer > - hardware runs the world, software controls the hardware > code generates the software, have you coded today?Article: 48569
Hi there, I have the following problem. A partner firm has a design implemented on a XILINX Virtex XCV800. The design is in VHDL and I want to check if this design can be ported to an ALTERA. Could anyone explain me the following terms that I get in the report of the XILINX Dev-Tool and give me the correspondig term for an ALTERA device ? - Slices - Slice reigster - LUT I think the LUTs are comparable to the ALTERA LUT arenīt they ? On epoint is that 342 LUTs are used as 32x1 RAM. If I interpret the ALTERA datasheet correctly I cannot implement ram in that small portions. Is there a way to implement RAM in LUTs ? Thanks in advance SvenArticle: 48570
Larry McKeogh wrote: > > Thomas, > please try: > http://www.xilinx.com/webpack/classics/wpclassic/ > > regards, > Larry > This exactly was the link I needed, thank you ThomasArticle: 48571
On Mon, 21 Oct 2002 05:49:16 GMT, allan_herriman.hates.spam@agilent.com (Allan Herriman) wrote: >On Sun, 20 Oct 2002 13:52:38 +0100, Rick Filipkiewicz ><rick@algor.co.uk> wrote: > >> >> >>Allan Herriman wrote: >> >>> On Sat, 19 Oct 2002 16:15:01 GMT, Ken McElvain <ken@synplicity.com> >>> wrote: >>> >>> >Thanks! Actually there are several of the hotline folks that read the >>> >newsgroup, but we limit the number of posters. >>> >>> Ah, good. I'd like to know what you are doing about the SRL16 >>> inference rule change between 7.0 and 7.1. We have a number of >>> designs here that break in 7.1 and 7.2 because Synplify Pro is >>> inappropriately changing FF into SRL16E. >>> >>> Problem 1 (fixed in 7.2 beta) Some FF with 350MHz clock get converted >>> to SRL16E. SRL16E don't work at 350MHz (in Virtex2). >>> >>> Problem 2 (still outstanding) Some FF with async reset get converted >>> to SRL16E. SRL16E don't have an async reset input, so this is a >>> functional change. >>> (It's that old problem of Synplify trying to be too clever about the >>> meaning of GSR when the startup block is present. If an FPGA has an >>> external reset input (connected to the startup block) then it is *not* >>> correct to assume that GSR is only active during configuration.) >>> >>> Problem 3 (still outstanding) Some FF that were in IOBs get converted >>> to SRL16E. This breaks the I/O timing on the part. >>> >>> Problem 3 is actually the worst one for us, since most of the designs >>> infer I/O FF. >>> >> >>Does `syn_useiobffs' stop it inferring SRL16Es ? If not this is a killer >>bug and mucho thanks for the warning as I was just about to make the move >>from 7.0.2 -> 7.2. > >Haven't tried that one. This is legacy code that doesn't have many >tool specific attributes. >In general, I don't like littering my code with attributes just to get >reasonable behaviour from the synthesiser, particularly when earlier >versions of the same synthesiser did the right thing. >But I guess it all hinges on the meaning of "reasonable" ... > >As we saw with the tristate buffer push through bug, tool vendors can >have a rather odd view of what customers want from their tools. > >>> >>> I rather liked the 6.x rule that only allowed an RTL FF to be >>> converted to SRL16E when the FF was coded without an async reset or >>> set. >>> >> >>In fact I can't see how Synplify can legally infer an SRL16(+/-E) for an FF >>with any sort of set/reset sync or async since the Xilinx primitive doesn't >>have a reset pin!. IIRC this was actually broken in 6.0beta and I had a I2C >>module shift reg with sync. clear inferred as an SRL16. Got fixed in 6.1 I >>think. > >Well, it seems to be broken again. Minor clarification: If the GSR net is connected to a ROC block, then the synthesiser can know that GSR is only active during configuration, and therefore it is safe to convert a FF (with async set or reset) into an SRL16(E). But the problem I was seeing had to do with an async reset net that had an external connection, therefore no conversion is possible. Regards, Allan.Article: 48572
Hi Casey, Some FIFOs have to have the "init" pin toggled before the simulation results are valid. Cheers PhilArticle: 48573
Does Foundation 4.2i support Spartan IIE???? AdrianArticle: 48574
What is the difference between ISE and ISE Foundation? Adrian
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