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
"Goulas George" <george_goulas@hotmail.com> writes: > > It's a bit irrelevant to this newsgroup... > > I need a drawing program that produces good looking digital circuit designs. > I've tried Visio, but I could n't find muxes or ffs. > I don't need all the graphic detail of the good digital > simulation programs, I just need to present some > circuits.... Good(?), old digilog from the Chipmunk tools package (www.google.com will help you locate it) should do the job if you have access to a *nix box. -sig -- sigurd urdahlArticle: 24426
I had not given this issue a lot of thought, but then I took a look at
the Xilinx web site to see just what was going on and I found out a lot.
The Foundation tools have been broken into two sets, the standard
schematic based tools and the new ISE tools. The base schematic tools
have gone up in price from $500 to $1000 with no useful additional
features or products that I can see.
The new ISE tools come with crippled simulation tools (Allstar tools).
The description says, "If your design needs exceed the capabilities of
the ALLSTAR tools, upgrades are available for purchase directly from
each of the partners. These upgrades utilize the same user interface of
the ALLSTAR tool, while providing increased performance and/or
capacity." But I can't find a description of the limitations of these
tools.
Not only is Xilinx now renting the tools vs. selling you the tools, they
are promoting support with "you get what you pay for" marketing.
The PLATINUM DPP adds:
- PLATINUM Hotline Service with premium access
- Access to engineers with increased expertise
- 8 Xilinx education credits (an $800 value)
So it appears that Xilinx is doing what Microsoft has done and created a
mechanism to get support and another mechanism to get "good" support for
a higher price.
Is it me, or is this something to get bugged about?
Rick Filipkiewicz wrote:
>
> Is it worth upgrading from 2.1iSP6 to the new s/w ? Any experiences good
> or bad ?
>
> Considering that I now have to pay the ``time based license'' fee aka
> `the shareholders are complaining and chip prices are competitive so
> lets make more money out of the s/w' I want to know what the benefits
> are, if any.
>
> I don't actually mind paying a fair bit for Xilinx s/w - our original
> total outlay up to XCV1000 was about UKP3500 - since in general its
> pretty good. But I do strongly object to it timing out after a year. I
> want to buy the s/w, not rent it.
>
> Note for the lawyers: Normally if you are renting something and it goes
> wrong its the responsibility of the owner to get it fixed or replaced.
> Does this mean I can demand an instant fix for any serious bug I trip
> over ?
--
Rick Collins
rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design
Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX
Internet URL http://www.arius.com
Article: 24427rickman wrote: > I had not given this issue a lot of thought, but then I took a look at > the Xilinx web site to see just what was going on and I found out a lot. > > The Foundation tools have been broken into two sets, the standard > schematic based tools and the new ISE tools. The base schematic tools > have gone up in price from $500 to $1000 with no useful additional > features or products that I can see. > That's the conclusion I sort of came to. As far as I can see all that ISE has done is to emulate the shining example of Visual C/C++. The only addition I can detect is that there is now, finally, some sort of source code revision control mechanism > > The new ISE tools come with crippled simulation tools (Allstar tools). > The description says, "If your design needs exceed the capabilities of > the ALLSTAR tools, upgrades are available for purchase directly from > each of the partners. These upgrades utilize the same user interface of > the ALLSTAR tool, while providing increased performance and/or > capacity." But I can't find a description of the limitations of these > tools. > Oh good. > > Not only is Xilinx now renting the tools vs. selling you the tools, they > are promoting support with "you get what you pay for" marketing. > > The PLATINUM DPP adds: > > - PLATINUM Hotline Service with premium access > This sort of thing is an indication that its time to design out the parts and sell your shares since the marketing people have staged a coup d'etat. > - Access to engineers with increased expertise > - 8 Xilinx education credits (an $800 value) > > So it appears that Xilinx is doing what Microsoft has done and created a > mechanism to get support and another mechanism to get "good" support for > a higher price. Maybe they've decided to really work at getting the tools as good as MS s/w. > > Is it me, or is this something to get bugged about? No its not just you so I suggest we Xilinx users all get seriously bugged together or we will most assuredly be bugged individually.Article: 24428
Michael Randelzhofer wrote: > Hi Xilinx Freaks, > > I'm doing my first Spartan2(XC2S50) design with Foundation 2.1i_sp6. > In my incremental design-process in vhdl, i want to check up the left > resources in the fpga after each design-step. > > The Place&route report only informs me about the used I/O's, 'slices' and > tbufs. > > In my design are lots of shiftregisters which do not need any lut, but if > only 1 > FF is used in a slice, the report seems to mark it as used. > So the slice-count could not help me to estimate the free resources. > > In former Xilinx fpga families, the report gave me the exact information > about > used flipflops, 4input-luts, 3input-luts and so on. > > Is there any other simple way to check the resources ? > I don't want to count the used luts in the fpga-editor, or in a netlist. > Is Foundation 3.1 a solution ? > > Thanks in advance > MIKE A much better source from the Xilinx tools is the MAP report file usually called <design>.mrp. Although PAR might add a few things here and there its insignificant. If you are using HDL synthesis then you can get the info from the post synth reports. If you want the whole MAP process report you will have to set the -detail flag.Article: 24429
XST is Xilinx Synthesis Technology and is included, I believe, with the new Foundation ISE 3.1i. Foundation ISE 3.1i is based, I believe, on the Synario Project Navigator and includes a schematic capture tool. <eml@riverside-machines.com.NOSPAM> wrote in message news:398a87b7.6740492@news.dial.pipex.com... > On Fri, 04 Aug 2000 00:51:56 -0400, Dave Vanden Bout <devb@xess.com> > wrote: > > >Xilinx Synthesis Technology? I know they use this to synthesize netlists from > >VHDL and Verilog in their WebPACK tools. > > I hadn't realised it was used on Webpack, but it comes with 3.1. I > don't know if it's priced separately or if it's a freebie. It's the > old Minc synthesiser, acquired (I think) along with the Synario stuff > a year or two ago, which is all re-appearing in 3.1, after some > development. I've only seen a demo, so I've got no real details, but > the project manager front-end will look very familiar to anyone who's > used Synario or the later Abels. I think the Synario schematic capture > tool is also included in the Project Manager, but I didn't see it. > > EvanArticle: 24430
rodger wrote: > > XST is Xilinx Synthesis Technology and is included, I believe, with > the new Foundation ISE 3.1i. Foundation ISE 3.1i is based, I believe, > on the Synario Project Navigator and includes a schematic capture tool. What is going on with the revamp of the tools in ISE 3.1? Does anyone have an idea of why Xilinx wants to change the toolset and start from scratch every year or two? Now instead of supporting two Foundation tools (Basic and Express), they are supporting seven different versions of the tools. And then they tell us that it is too much support work to give out the bitstream information... ??? The one I really don't get is the Elite packages. The Express package supports every part other than the Virtex E > 1 million gates. For those largest two or three parts, they make you use a different package. Is there some special reason for that??? -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24431
You might check out an article in the March 2000 isd magazine (page 22-30) by Peter Alfke. "Moving Data across Asynchronous Clock Boundaries" It has some good information highlighting the problems with moving data between clock domains. Regards, Chris Fritz Freestone Systems Inc. K. Orthner <korthner@hotmail.nospam.com> wrote in message news:8F897D1AAkorthnerhotmailcom@158.202.232.7... > I'm working on a design where I have two clock domains. > > I've decided to implement everything crossing the two domains using FIFOs, > both BlockRAM-based, and distributed RAM based. > > I've looked at two application notes that deal with this, One aimed at the > Spatan-II, and one for the 4000 series. > > In the appnote for the 4000 series (XAPP051, 1996, Peter Afke), Grey > counters are used to improve speed and to simplify the generation of the > FULL and EMPTY signals to prevent "weird" states. The new appnote for > Spartan-II (XAPP175, 11/99) discusses pretty much the same thing, using > grey counters and what-not, as well as keeping copies of "next_pointer"s > make full and empty synchronous signals. > > The new appnote doesn't seem to consider how to prevent problems arising > from using the two clock domains, however. I've copied what it said below, > for anyone who wants to read it. > > In the old appnote, it suggested using latches, to latch the empty/fuill > signal that was generated in the other clock domain, and then re-clocking > the output of the latch with the desired clock. > > So, my question is, is it really suggested to use a latch at the output of > simple combinatorial logic to "stretch" the full/empty signal and then re- > clock it? > > I'm somewhat new to working in two clock domains, and I would rather figure > it all out now, as I'm doing my design, then later when I'm dabugging it. > > Thanks a million. > > -Kent > > > From XAPP175: > > "To solve this problem, and to maximize the speed of the control logic, > additional logic complexity is accepted for increased performance. There > are primary 9-bit Read and Write binary address counters, which drive the > address inputs to the Block RAM. The binary addresses are converted to > Gray-code, and pipelined for a few stages to create several address > pointers (read_addrgray, read_nextgray, read_lastgray, write_addrgray, > write_nextgray) which are used to generate the Full and Empty flags as > quickly as possible. Gray-code addresses are used so that the registered > Full and Empty flags are always clean, and never in an unknown state due to > the asynchronous relationship of the Read and Write clocks. In the worst > case scenario, Full and Empty would simply stay active one cycle longer, > but this would not generate an error." >Article: 24432
"Domagoj" <domagoj@engineer.com> wrote in message news:8majcd$523$1@bagan.srce.hr... > one of disadvantages : if you are planning to port your design to ASIC > some day, or maybe to another FPGA family without tbufs, you'll probably > need to rewrite your code again. so, using plain old muxes implemented in > luts enhance portability. What about the Automatic replacement of internal Tristates available in Synthesis tools.? Andrew InceArticle: 24433
rickman wrote: > > SRAM modules are not terribly common although they do exist. Much more > common are DRAM modules although standard DRAM and EDO DRAM are being > phased out. SDRAM and DDSDRAM (or whatever the acronym is for double > data rate SDRAM) are the newer standards with more years left in them. > > SRAMs are easy to get as chips (other than for allocation problems >:). > But you mention that you want density. EEPROMs are much more dense than > SRAM. EEPROM in the Flash form are nearly as dense as DRAM and about 16 > times more dense than SRAM. I can get 64 Mbit Flash chips but I don't > think anyone is making async SRAM bigger than 4 Mbit. Sync SRAMs (the > stuff they use as PC cache memory) comes up to 8 or 16 Mbit, IIRC. > > Of course Flash is much slower than SRAM, but you didn't say what speeds > you need. If you don't need speed, SDRAM can be faster than Flash, but > you need a more complex controller. Of course that all depends on what > you are connecting it to. > > Sound complicated? It is! Until you learn about the different memory > flavors. Do you sugest me any book? Thanks again, RodolfoArticle: 24434
Rodolfo Jardim de Azevedo wrote: > > rickman wrote: > > > > SRAM modules are not terribly common although they do exist. Much more > > common are DRAM modules although standard DRAM and EDO DRAM are being > > phased out. SDRAM and DDSDRAM (or whatever the acronym is for double > > data rate SDRAM) are the newer standards with more years left in them. > > > > SRAMs are easy to get as chips (other than for allocation problems >:). > > But you mention that you want density. EEPROMs are much more dense than > > SRAM. EEPROM in the Flash form are nearly as dense as DRAM and about 16 > > times more dense than SRAM. I can get 64 Mbit Flash chips but I don't > > think anyone is making async SRAM bigger than 4 Mbit. Sync SRAMs (the > > stuff they use as PC cache memory) comes up to 8 or 16 Mbit, IIRC. > > > > Of course Flash is much slower than SRAM, but you didn't say what speeds > > you need. If you don't need speed, SDRAM can be faster than Flash, but > > you need a more complex controller. Of course that all depends on what > > you are connecting it to. > > > > Sound complicated? It is! Until you learn about the different memory > > flavors. > > Do you sugest me any book? > > Thanks again, > > Rodolfo No one book, but go to the web sites for several of the memory manufacturers and read the datasheets, the app notes and the selection guides for all of their parts. Some good sites to visit are Micron, Samsung and Intel. Micron data sheets are very clear and they have good app notes. Samsung has a nice variety of parts. Intel has a poor web site that is hard to navigate, but they sell a lot of Flash and have some rather unique parts. I don't think you will find much of this stuff in a text book of any kind. Summary: Async SRAM - Fast to slow, no clock, no overhead for first access. Sync SRAM - Fast, clock up to 200 MHz(?), one or two clock overhead for first access. EEPROM - Moderately slow, no clock, no overhead for first read, erase and write bytes. Async Flash - Moderately slow, no clock, no overhead for first read, must erase in blocks. Sync Flash - I have not used this (or even looked at it yet) but Micron (or is it Samsung?) claims it is compatible with SDRAM. Sync DRAM - Fast, up to 133 MHz clock, multiple cycle delay for first read or write, fast block read/writes. DD DRAM - Like Sync, but transfers data on each clock edge. RAMBUS - Sync DRAM with a special very high speed interface up to 400 MHz(?), used in high end PCs. There are others, but they are for special applications and cost more or a lot more money. -- Rick Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 24435
Some books that might be of interest. Look at things written by Betty Prince. She has two books out I think, both of which may be in the second edition. They are fairly detailed. Micron's free book about what they sell is an interesting read if you take your time. I learned a lot from it. Both of these can be fairly detailed and neither are really what you are really looking for, but the info you want is likely inside of both. Careful web searching might help too. If your company is willing to hire someone to get you all up to speed, you might try Ms. Prince. She comes across as quite knowledgeable and is available for such things. (I've only met her once.) Best of luck, Mark In comp.arch rickman <spamgoeshere4@yahoo.com> wrote: > Rodolfo Jardim de Azevedo wrote: >> >> rickman wrote: >> > >> > SRAM modules are not terribly common although they do exist. Much more >> > common are DRAM modules although standard DRAM and EDO DRAM are being >> > phased out. SDRAM and DDSDRAM (or whatever the acronym is for double >> > data rate SDRAM) are the newer standards with more years left in them. >> > >> > SRAMs are easy to get as chips (other than for allocation problems >:). >> > But you mention that you want density. EEPROMs are much more dense than >> > SRAM. EEPROM in the Flash form are nearly as dense as DRAM and about 16 >> > times more dense than SRAM. I can get 64 Mbit Flash chips but I don't >> > think anyone is making async SRAM bigger than 4 Mbit. Sync SRAMs (the >> > stuff they use as PC cache memory) comes up to 8 or 16 Mbit, IIRC. >> > >> > Of course Flash is much slower than SRAM, but you didn't say what speeds >> > you need. If you don't need speed, SDRAM can be faster than Flash, but >> > you need a more complex controller. Of course that all depends on what >> > you are connecting it to. >> > >> > Sound complicated? It is! Until you learn about the different memory >> > flavors. >> >> Do you sugest me any book? >> >> Thanks again, >> >> Rodolfo > No one book, but go to the web sites for several of the memory > manufacturers and read the datasheets, the app notes and the selection > guides for all of their parts. Some good sites to visit are Micron, > Samsung and Intel. Micron data sheets are very clear and they have good > app notes. Samsung has a nice variety of parts. Intel has a poor web > site that is hard to navigate, but they sell a lot of Flash and have > some rather unique parts. > I don't think you will find much of this stuff in a text book of any > kind. > Summary: > Async SRAM - Fast to slow, no clock, no overhead for first access. > Sync SRAM - Fast, clock up to 200 MHz(?), one or two clock overhead for > first access. > EEPROM - Moderately slow, no clock, no overhead for first read, erase > and write bytes. > Async Flash - Moderately slow, no clock, no overhead for first read, > must erase in blocks. > Sync Flash - I have not used this (or even looked at it yet) but Micron > (or is it Samsung?) claims it is compatible with SDRAM. > Sync DRAM - Fast, up to 133 MHz clock, multiple cycle delay for first > read or write, fast block read/writes. > DD DRAM - Like Sync, but transfers data on each clock edge. > RAMBUS - Sync DRAM with a special very high speed interface up to 400 > MHz(?), used in high end PCs. > There are others, but they are for special applications and cost more or > a lot more money. > -- > Rick Collins > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > Internet URL http://www.arius.com -- ~~~~~~~~~~~~~~~~ http://www.cps.msu.edu/~brehob ~~~~~~~~~~~~~~~~~~ | | The reports of SIMD's death have been greatly exaggerated | | | -=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | ~~~~~~Mark Brehob: Ultimate Player, Gamer, Computer Geek~~~~~~~~~~Article: 24436
In article <8mk8ue$en6$1@foo.grnet.gr>, "Goulas George" <george_goulas@hotmail.com> wrote: 1. Start news . 2. goto alt.binaries.warez.ibm-pc.0-day 3. extract rbs-ct01.zip through rbs-ct-04.zip . 4. The ".diz" file reads : CircuitMaker 6.2 & TraxMaker 3.03 Pro ______________________________[xx/04] \_ _ \_ ____/_ _ \_ ____/ |_\ ___/ / _/ ___)/ _/ ___) | \___ \ / | \_ | \ | \ | \ : \ : \ \___| /___ \____ \___ \___ \___ \ ====|__/===\__/===\__/==\__/==\__/==\__/ REBELS: WE MAKE ALL DAYS PARTY DAYS >> RELEASING WITHOUT PERMISSION << Hope it helps. >It's a bit irrelevant to this newsgroup... > >I need a drawing program that produces good looking digital circuit designs. >I've tried Visio, but I could n't find muxes or ffs. >I don't need all the graphic detail of the good digital >simulation programs, I just need to present some >circuits.... > >Thanks in advance > > >Article: 24437
I am a FPGA newbie. Can anyone tell me some good FPGA introduction papers? Thanks. DanArticle: 24438
We are getting a very strange error when using the Xilinx, Foundation Series, Design Manager software, to create a bit file implementation for our 4010XLPC84 Xilinx chip, durring the mapping stage. ERROR:baste:263 - The LOC constraint "P69" (a IOB location) is not valid for symbol "DS<0>.PAD" (pad signal=DS<0>), which is being mapped to the following site types: CLKIOB What we are doing here, is we have a std_logic_vector named DS that we are trying to map to some pins in a UCF file. For some reason, it generates this error, and I have been unable to find any documentation on this error. If anyone out there has encountered this error, how did you solve it? Thanks. Nick PappasArticle: 24439
On Tue, 08 Aug 2000 12:49:24 -0400, Nicholas Pappas <npappas@vt.edu> wrote: >We are getting a very strange error when using the Xilinx, Foundation >Series, Design Manager software, to create a bit file implementation for >our 4010XLPC84 Xilinx chip, durring the mapping stage. > >ERROR:baste:263 - The LOC constraint "P69" (a IOB location) is not valid >for symbol "DS<0>.PAD" (pad signal=DS<0>), which is being mapped to the >following site types: CLKIOB > >What we are doing here, is we have a std_logic_vector named DS that we >are trying to map to some pins in a UCF file. For some reason, it >generates this error, and I have been unable to find any documentation >on this error. If anyone out there has encountered this error, how did >you solve it? Thanks. > Are you using DS<0> as a clock input to any flip flop in your design? Maybe inadvertedly?. It looks to me as your synthesis tool connects DS<0> directly to a BUFG, but P69 is no BUFG'able input just a theory, chm. -- cmautner@ - Christian Mautner mail.com - Vienna/Austria/EuropeArticle: 24440
I could spend an hour or two and give a more detailed answer, but I am fairly sure you have a bug to report. The problem is at least that PAR should be telling you that it can't create the thing you want for some of these cases. To help guide you to an answer, it may help to know that the FF is really two latches, the first is transparent when clock is low, the second is transparent when clock is high (assuming no CLB level clock inversion). To implement a latch, I suspect that an additional config bit permanently holds the second latch transparent. This avoids the alternative, which is a bypass around either of the latches, which would screw up timing, such as Tcko. Since the first latch is the remaining one that is used, it is a transparent low latch (again assuming no CLB level clock inversion). You will also see this in the Xilinx libraries guide for the XC4000X/XL, LDCE_1 is the primitive, the rest are macros. The libraries guide lies that all the different versions of latches are primitives in the Virtex chips. (although that may be a netlist issue. If for 4KX/XL, the only valid prim is LDCE_1, and others are transformed at netlisting time, and for virtex, all forms are allowed in the netlist, and PAR sorts it out, I guess the guide could be argued to be ok) My guess is that the bug you are facing, is the PAR code that handles latches for Virtex, is quietly changing the clock sense, oblivious to the fact that other things in the CLB use the clock too. Good luck trying to get Xilinx to understand, acknowledge, and fix it. Philip Freidin On Sun, 06 Aug 2000 06:10:27 GMT, "Jan Gray" <jsgray@acm.org> wrote: > >Then I thought, hey, in my application a latch might do. >Not pretty, but the latch output is then reregistered in half >a clock anyhow. > >But when I implemented a simple latch and looked >at its configuration in the FPGA Editor, I was surprised to >see that PAR had set the slice clock inverter. I checked the >edif that came out of Foundation Express for my latch, and >it looked right, a simple instance of LD with no CLK inversion. >Should pass data on CLK high and hold it on CLK low. > >Then I tried some more experiments, and I found that > >1. when I constrain a rising edge triggered single-port RAM > and a G=clk latch into the same slice, it passes PAR, but curiously, > FPGA Editor again shows the slice clk mux selects inverted CLK > for both! > >2. when I constrain the same RAM and latch to be in different slices, > the RAM slice shows up as rising edge triggered, but the latch > slice again shows up with CLK inverted! > >3. when I constrain a rising edge triggered single-port RAM and > a G=~clk latch in the same slice, it fails PAR with the error > > ERROR:xvkpu - Unable to obey design constraints (LOC = CLB_R3C1.S1) which > require the combination of the following symbols into a single slice: > RAM symbol "r2" (Output Signal = o2) > LATCH symbol "q2_reg" (Output Signal = q2) > The clock signals don't agree. > >I expected 3. But I really don't understand why inverted CLK >is selected for the RAM and the latch in cases 1 and 2, and at >any rate why cases 1 and 2 don't receive identical CLK polarities. >This feels like a bug, either in PAR, or in FPGA Editor. > >Any ideas? >Thanks. >Jan Gray >Gray Research LLC Philip Freidin Mindspring that acquired Earthlink that acquired Netcom has decided to kill off all Shell accounts, including mine. My new primary email address is philip@fliptronics.com I'm sure the inconvenience to you will be less than it is for me.Article: 24441
In article <8mlhal$ps3$1@atom.nectec.or.th>, "Phunjapa Ruangsinsup" <mpr@siampage.com> wrote: > I must design asynchronous circuit on FPGA and I must know Gate-delay and > interconnection delay for create Complete signal check (the signal which > have delay longest than another in circuit). I design by RTL-VHDL code and > synthesis by Xilinx Foundation 2.1i, my synthesis output is VHDL and SDF > code. So can i use delay report from SDF code to be a Gate-delay?? and Where > i can see interconection-delay of each signal?? > > What you are looking for is the output of PAR tools, not synthesis tools, since the synthesis tools can only estimate the delays. Use the timing analyzer GUI or trce to obtain the timing report. Gate to gate ptopagation is not going to be easy to find out, since synthesis tools and then PAR tools will try to optimize your logic. You can only rely on registers still being there (with some exceptions). If the synthesis tool did not optimize away the nets of interest then you can ask PAR tools to KEEP them, so that when you run the timing analyzer you can examine the paths pertinent to those nets. FPGAs are much more suitable for synchronous design. What you are trying to do is not easy and very much part-batch dependent. Good luck -- Yury Wolf Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24442
In article <39903A14.526BD890@vt.edu>, Nicholas Pappas <npappas@vt.edu> wrote: > We are getting a very strange error when using the Xilinx, Foundation > Series, Design Manager software, to create a bit file implementation for > our 4010XLPC84 Xilinx chip, durring the mapping stage. > > ERROR:baste:263 - The LOC constraint "P69" (a IOB location) is not valid > for symbol "DS<0>.PAD" (pad signal=DS<0>), which is being mapped to the > following site types: CLKIOB > > What we are doing here, is we have a std_logic_vector named DS that we > are trying to map to some pins in a UCF file. For some reason, it > generates this error, and I have been unable to find any documentation > on this error. If anyone out there has encountered this error, how did > you solve it? Thanks. > > Nick Pappas > Did by any chance that pin get prohibited in UCF file from being used? Check .pcf file as well. P69 is special in that it is used for configuration in Master parrallel and peripheral modes. Make sure that the pin name listed in ucf/pcf file has the same name as the I/O bus pin in HDL code. If you are using UCF it should be called DS<0>. In VHDL code it would be DS(0). Yury Wolf > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 24443
You could send it out byte-wise to a hot link interface. it will operate at up to 400Mbit/sec. Cards for PCI bus interface exist.Article: 24444
Goto the www.micron.com site. They provide Verilog and VHDL models for all of their RAMs. YOu probably want to use either Sync DRAM or ZBT sync SRAMs. Rodolfo Jardim de Azevedo wrote: > > Hi, > > I'm trying to make an experimental board which will use 2 modules of > memory. I will write some VHDL code and use a FPGA to implement it. But > I could not find some information yet. I need SRAM modules (I think some > PCs use them as cache memory, that would be the best choice). Where can > I get some specification of such modules? How to make an interface? > (pinouts, time diagrams, ...) > In fact, I could even use EEPROMs, because I don't need to change the > system memory too much. But I would prefer SRAM modules due to space > constraints in my board. > > Thanks in advance, > > RodolfoArticle: 24445
Hal Murray wrote: > > > This was triggered by the recent debate over the delay differences > > between the 4 different LUT inputs. I feel strongly that the > > designers should not be bothered with such details. The software > > should analyze and synthesize this for you. Yes but I like to know what my software is doing. There is times you add logic to help with timing delays and logic hazards. Not that often but you do. Here we have 2x clock generating a enable for a latch. If the software does somthing stupid with my NOR gate I could end up with wrong data. ><~~><~~ --__--__ clock __--____ enable ---+[T Q]--o[&] -[D Q] +-------o[ ]-----[E ] > Software has a long history of not being smart enough to do the > right thing. > > So independent of whether the numbers are in the data sheet or > we have to get them from a tool, I think it's important for the > designer to understand the low level issues AND for there to > be some path to make the software do what the designer wants > when he is smarter than the software. Having just downloaded Altera's FPGA software have been playing around with the TTL macros to get a feel for the software. Using some 74181's I can get a carry out in about 50 ns or 100 ns whether the logic is optimized for speed or size. Reading the data sheet for the for using fast ripple carry adder I would get a delay about 25 ns. This gives me now a good idea depending on the rest of my circuit timing to stick with the 181 ALU or design my own. Since this my first design I will stick with the TTL macros but know that the ALU could use improvment down the road. Ben. PS, The printed page or data book is handy at 3am when happen to think of a better way to do something and the office with your computer is Locked up for the night. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Octal Computers:Where a step backward is two steps forward!" http://www.jetnet.ab.ca/users/bfranchuk/index.htmlArticle: 24446
robby75@my-deja.com wrote: > > Hi FPGA freaks, > > Can you, please, enumerate the advantages and disadvantages of a > microprocessor with an on-chip reconfigurable logic. A year ago, > Triscend have anounced the first Micro-controller with reconfigurable > logic (configurable system on a chip CSoC). Apart from Xess who have > developed a board based on CSoC, I did not hear much about it. > The idea seems great and dates from some time now. Are there any > practical limitations? > Are not the computers on Star Trek all reconfigurable logic !? and you know the problems they have had. With a bad bug or virus in regular logic your program or HD dies. With a bad bug or virus for reconfigurable logic everything could die, or be hard to kill. Hmm a HAL 9000 toaster -- Dave is that you! my vision circuits are not working here. Ben. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Octal Computers:Where a step backward is two steps forward!" http://www.jetnet.ab.ca/users/bfranchuk/index.htmlArticle: 24447
FYI, I received my copy via UPS about a month or two ago. Andy Andy Peters <apeters.Nospam@nospam.noao.edu.nospam> wrote in message news:8mmp4c$1rql$1@noao.edu... > peter dudley wrote in message <8mk3gg$9gg$1@abq-news-01.ihighway.net>... > >Last December I bought the Xilinx Alliance Base software for some home > >projects that I had to do. Since then 3.1i has come out. > > > >Does anyone know if I should receive a free update on this software? > > If you've paid the maintenance ransom, you should receive the 3.1i software. > > At least, that's what I'm told. I'm still waiting for the software. > > > -- a > ----------------------------------------- > Andy Peters > Sr Electrical Engineer > National Optical Astronomy Observatories > 950 N Cherry Ave > Tucson, AZ 85719 > apeters (at) noao \dot\ edu > > "A sufficiently advanced technology is indistinguishable from magic" > --Arthur C. Clarke > > >Article: 24448
rickman wrote: <The gate counting that they do is a little complicated since they have < to make some assumptions for how much of the block ram to count as well > as what modes you will use the other features in. So I don't think you > will be able to figure it out without contacting them directly. Peter answers: Here is what I explained more than a year ago. The numbers refer to an XC4000-XL part, but the concept is similar for Virtex. Gate count is a borderline meningless number when applied to LUT-based FPGAs, with large amounts of RAM on-chip, plus dedicated ( hidden and un-counted ) carry logic, sophisticated clock manipulation, and multi-standard I/Os. But as amanufacturer we have to come up with a number, and market the devices in a competitive environment. Anyhow, here is the old explanation from early 1999: Let me explain the 10,982 Logic Cells, 147 k bits of RAM and 265000 max logic gates claimed for the XC40125XV. This is a mixture of engineering specifications and marketing. Engineering specifications: The XC40125XV has a 68 x 68 array of CLBs = 4624 CLBs Each of these CLBs has 32 RAM bits = 147 968 RAM bits total. No ifs and no buts. Now we get into marketing: Since this is a competitive world, our users want to compare different manufacturers, but the structures are not the same. Altera puts eight LUTs in a block, Lucent puts four, and we put two LUTs into a CLB, but everybody's LUTs are more or less identical. So Xilinx decided to standardize the nomenclature and emphasize not CLBs but rather Logic Cells, as a lingua franca for FPGAs. Good idea! Then marketing saw the third LUT in our CLB and gave it a value of 3/8 of a Logic Cell, so the whole CLB is worth 2.375 LCs. Obviously, we can argue about this addition, but it is true that one can use the third LUT for some really nice and efficient solutions. :-) Multiply the 4624 CLBs by 2.375 and you get 10 982 Logic Cells. What is that in ASIC gates? There is no scientific answer, because it depends on the design. What is the LUT being used for, is the flip-flop being used at all, and what if you use the LUT as RAM ? Assume that every LUT is worth 6 gates and every flip-flop is worth 6 gates, then every Logic Cell is worth 12 gates (sometimes more, sometimes less). 12 gates times 10 982 LCs makes a bare-bone gate-count of 131 784, and that is reflected in the name of the device. We are conservative and round it down a little. :-) But there is the RAM in the LUT, and if only 25% of them are really used as RAM, these LUTs are not worth 6 gates, but rather 64 gates (16 bits with 4 bits per RAM cell, again, very conservative, ignoring the select structure and the read/write circuitry). That means, we must add another 58 gates times 25% of 9248 LUTs, which means another 134 096 gates, for a total of 265 880 logic gates. And we say explicitly that this assumes 20 to 30 % of the CLBs being used as RAM. That's how the XC40125XV got its name and its gate-count range of 125,000 to 265,000 gates. It is an attempt to bring some sanity to the gate-count confusion. Users will never agree about these assumption, and if you don't want to compare different manufacturers, then you can forget the whole thing and just stick with CLBs and RAM bits, for they are physical and thus non-controversial. Peter Alfke February 27, 1999Article: 24449
Hello everybody, I am happy to announce OpenCores will be doing its first silicon (TSMC 0.25u, 5LM) using its current open source cores. Current idea is to put together three 32-bit RISC cores (OR1320 + 2x OR1601), SDRAM & master PCI controller, 2x Ethernet MAC, 2x serial UART, RTC & WDT. Something similar like Intel's IXP1200 network processors. First operating system for the chip will probably be Linux (also eCos and RTEMS will be ported). Since all cores are more or less still under development we would like to invite more people to help us. Help is especially needed on Ethernet MAC and PCI master cores. Also all other teams welcome any additional help. Prefered HDL to be used for _current_ chip is Verilog (unless you can supply netlists for Artisan 0.25u TSMC). If you would like more information about OpenCores's mission and current project please visit us at http://www.opencores.org/. Currently details about silicon project are not yet published. regards, Damjan -- mailto:lampret@opencores.org http://www.OpenCores.org Sent via Deja.com http://www.deja.com/ Before you buy.
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