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've received reports that the DCM module from the Xilinx unisims
library is not working under Icarus Verilog, and I find in the
module this code to set the lock_period flag:
if (period < clkin_edge[0] - clkin_edge[1] - 500)
lock_period <= 0;
else if (period > clkin_edge[0] - clkin_edge[1] + 500)
lock_period <= 0;
else if ((clkin_edge[0] != 1'bx) && (clkin_edge[1] != 1'bx))
lock_period <= 1;
The "!= 1'bx" expressions in the third if statement are highly
suspicious. Those expressions should, as written, evaluate to
1'bx no matter what the value of clkin_edge[0] or [1], and that
lead to the final if case never being executed. Or at least that
is how I understand it, even when I read the Verilog standard
sideways.
So does this bit of code work for anybody? Does lock_period get
set for anybody who uses the DCM module from the Xilinx unisims
library?
Incidentally, replacing != with !== should fix it. I believe the
author is trying to check that the clkin_edge values are defined.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
abuse@xo.com
uce@ftc.gov
Article: 42576One problem I had a while ago with a Spartan-II datasheet was it didn't say that Spartan-II IOB tri-state buffers are active low or high. However, figures in the datasheet show OBUF and IOBUF don't have a bubble in front of their OE (Output Enable) input, so I assumed that tri-state buffers are active high. Assuming that IOB tri-state buffers are active high, I tried to push IOB FFs into IOBs, but didn't work. After some investigation of past postings at news:comp.arch.fpga, I saw some people saying that Virtex IOB tri-state buffers are active low, so to confirm that, I did a search of Xilinx support page, and there I finally found a page that said Virtex architecture's IOB tri-state buffers are active low. Why isn't such basic information not in the datasheet? Does Xilinx assume that everyone who use Xilinx devices already know that? I didn't know that IOB tri-state buffers are active low because I had very little experience dealing with FPGAs back then. Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.) Peter Alfke wrote: > > Rick, and others: > We at Xilinx are very interested in any constructive suggestions how we can > make our documentation, especially in my case the data sheet, clearer and > easier to use. > > My present idea ( for future data sheets) is a 3-tier hierarchy > First a couple of pages of bullets and basic tables, device package > combinations, and even the ordering info. > Second about 20 pages with a sequence of terse descriptions of every (every!) > feature, enough for te "normal" user, with extensive references to the third > section. This second section act as a guide, preventing anybody from getting > lost. > The third section then spends as much space as needed to describe the subject > in detail. That might be a hundred pages for some features, like > microprocessors or Multi-Gigabit Transceivers. > > The information is all there, even today. The problem is finding it... > > Peter Alfke, Xilinx Applications >Article: 42577
Peter Alfke wrote: > > Nicholas Weaver wrote: > > > I > > > > Agreed. I LOVE that diagram on the XC4K datasheets. I'd love to see > > the equivelent for Virtex/Virtex II family parts. > > > > It would also be a good "WHoah, there is a lot of routing" picture. > > :) > > > > These drawings (and others) were killed because we did not want to call undue > attention to the internal complexity of the FPGA structure. Especially when > the main competitor brags about his no-brainer automatic "push-button" > design. :-( > There is a fine line between explaining all the details and exotic > capabilities, and scaring potential customers off. ?! Sounds like a line from the marketing dept - ( perhaps they are the ones scared of complex documents ). I have not found a real user yet that complained about too much detail, and these days, of non-printed manuals there is little cost to more detail. ( there are plenty that grumble about what's not in the data sheets ) The latest CoolRunner is a good example. The docs are so simplistic, I decided the only way to understand just what would map onto the HW, was do some test cases, and hope the reports were up to it. > Unfortunately, the documentation cannot be censored or easily be > adapted to the intelligence ( or level of friendliness, patience, > and dedication ) of the user. I don't know, your idea of 3 tiers sounds pretty good to me. ( way more appealing than any sentance containing the words 'scaring potential customers off') -jgArticle: 42578
In static logic, to implement a gigantic OR function, one may instead stack up multiple layers of OR gates in order to optimize for performance. How does LUT work, is it any different? If I want to implement an OR function with lots of inputs, does LUT do it better, or in otherwords, how does the FPGA compiler optimize this using LUTs? JimmyArticle: 42579
It's the old confusion between output enable and tristate, which obviously are the opposite of each other. But we should, therefore, make it redundantly absolutely and perfectly clear that active High OE is identical with active Low 3-state ( and vice versa). Life is too precious to be wasted on such silly misunderstandings. Peter Alfke, Xilinx Applications ============================================= Kevin Brace wrote: > One problem I had a while ago with a Spartan-II datasheet was it didn't > say that Spartan-II IOB tri-state buffers are active low or high. > However, figures in the datasheet show OBUF and IOBUF don't have a > bubble in front of their OE (Output Enable) input, so I assumed that > tri-state buffers are active high. > Assuming that IOB tri-state buffers are active high, I tried to push IOB > FFs into IOBs, but didn't work. > After some investigation of past postings at news:comp.arch.fpga, I saw > some people saying that Virtex IOB tri-state buffers are active low, so > to confirm that, I did a search of Xilinx support page, and there I > finally found a page that said Virtex architecture's IOB tri-state > buffers are active low. > Why isn't such basic information not in the datasheet? > Does Xilinx assume that everyone who use Xilinx devices already know > that? > I didn't know that IOB tri-state buffers are active low because I had > very little experience dealing with FPGAs back then. > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.) > > Peter Alfke wrote: > > > > Rick, and others: > > We at Xilinx are very interested in any constructive suggestions how we can > > make our documentation, especially in my case the data sheet, clearer and > > easier to use. > > > > My present idea ( for future data sheets) is a 3-tier hierarchy > > First a couple of pages of bullets and basic tables, device package > > combinations, and even the ordering info. > > Second about 20 pages with a sequence of terse descriptions of every (every!) > > feature, enough for te "normal" user, with extensive references to the third > > section. This second section act as a guide, preventing anybody from getting > > lost. > > The third section then spends as much space as needed to describe the subject > > in detail. That might be a hundred pages for some features, like > > microprocessors or Multi-Gigabit Transceivers. > > > > The information is all there, even today. The problem is finding it... > > > > Peter Alfke, Xilinx Applications > >Article: 42580
Any one LUT takes 4 inputs (any function you want). You can then concatenate LUTs through the carry chain at no extra cost in area, and about 30 ps additional delay per LUT used. Peter Alfke, Xilinx Applications ================================ crackeur wrote: > In static logic, to implement a gigantic OR function, one may instead stack > up multiple layers of OR gates in order to optimize for performance. How > does > LUT work, is it any different? If I want to implement an OR function with > lots of inputs, does LUT do it better, or in otherwords, how does the FPGA > compiler optimize this using LUTs? > > JimmyArticle: 42581
Hi. I chack the possibility to produce a module chip that in composed from 1 fpga die + a die of my chip packed together. Is there any fpga vendor that sell unpackaged (naked) dies ? Thanks ; Nurit.Article: 42582
strut911 wrote:
> hi john,
> thanks for the response. the simulator i am using is cadence
> NC-Verilog 3.3. it is a good simulator, and one of the standard
> verilog simulators in the asic industry. the problem is that if you
> compile two modules with the same name within the same design, it will
> exit with an error. i can understand the safety precautions that this
> check implements, but in the asic flow, you can uniquify your netlist
> which would eliminate these problems. Synopsys Design Compiler is
> conducive to a modular type of design flow, but i find increasingly
> that synplicity does not work that way. the main reason i would like
> to create a modular design where i can individually synthesize parts
> is that i would like to floorplan critical areas, and not have to
> touch them ever again. this would be an incredible help to me. i would
> normally sing the praises of synplicity, but i really wish that they
> could implement something like this. either that or maybe i have not
> come across a solution or workaround yet.
> strut911
I do this ``bottom up'' stuff as well at least to the extent that I have
one top level module which instantiates a number of level 2 modules each
of which is synthesised separately. Here's what I do.
It works for ModelSim and there should be some equivalent for NC.
o First I don't normally directly post-synth simulate but use NGDBUILD to
glue all
the various edif netlists together and then generate a post-NGD
netlist. Only if I find an
error while simulating this and cannot track it down directly (this is
rare) then ...
o ... I pre-process each of the .vm post-synth netlists to do these
things
- Remove the LUT module defintions
- Change the LUT instantiations to be compatible with the Xilinx unisims
lib. i.e.
LUT4_WXYZ -> defparam INIT = WXYZ; LUT4 ...
- Remove all the other module definitions to a separate library. Call it
e.g. synplify_lib or
some such. [the reason behind this is that the unisims FF models are
IMO a load of rubbish].
o Now compile each of the modified .vm files into a library and also
synplify_lib
o When starting ModelSim I give it a long list of `-L <compiled.vm>' flags
followed by `-L unisims' and
`-L synplify_lib'.
This gets around the mutliple LUT problem but does not get around the
issue where I'm instantiating some common module in several of the level 2
ones e.g. a FIFO. Unless the common module is synthesised with
"syn_hier=hard" 2 different .vm netlists may contain this FIFO
instantiated under the same name but with different port definitions as
Synplify has optimised across the boundaries.
For ModelSim the trick is to make `-L work' the first library definition
on the startup command line.
What this this tells the simulator is to always use the current library to
satisfy an instantiation. [I used to use yet another Perl script that
messed around with `uselib]. I think this should work for any Verilog-XL
compatible simulator.
Note that this idea of compiling all the .vm (or modified .vm) files into
separate libs allows mixed RTL/synth simulations; only using the .vm for
the suspect level 2 module.
Article: 42583Jason Moore wrote: > Hi Andrew, > You can use the Parallel Cable for Chipscope. I use it to demonstrate > the functionality of the tool and nearly all of my customers use it > instead of MultiLinx. It supports the transfer of data in both > directions PC -> FPGA and FPGA -> PC. As you said the only difference > is speed. > > Thanks > Jason > > The parallel-3 cable uses one of the dedicated Centronics printer->PC control lines to return TDO data.Article: 42584
Peter Alfke wrote > These drawings (and others) were killed because we did not want to call undue > attention to the internal complexity of the FPGA structure. Especially when > the main competitor brags about his no-brainer automatic "push-button" > design. :-( I guess these diagrams were at their most complete in the ORCA data sheets, and where did it get them :-) Maybe in an appendix?Article: 42585
Hi all, I have a Virtex xcv1000 laying on a board, and a Multilinx cable. Can anyone tell me if there is some way to pass test vectors to a downloaded design through Multilinx and the software provided by ISE 4.1, and also read the outputs and save them in a file? I really need any availiable help with this!Article: 42586
thanksArticle: 42587
Peter Alfke wrote: > > Nicholas Weaver wrote: > > > I > > > > Agreed. I LOVE that diagram on the XC4K datasheets. I'd love to see > > the equivelent for Virtex/Virtex II family parts. > > > > It would also be a good "WHoah, there is a lot of routing" picture. > > :) > > > > These drawings (and others) were killed because we did not want to call undue > attention to the internal complexity of the FPGA structure. Especially when > the main competitor brags about his no-brainer automatic "push-button" > design. :-( > There is a fine line between explaining all the details and exotic > capabilities, and scaring potential customers off. Unfortunately, the > documentation cannot be censored or easily be adapted to the intelligence ( > or level of friendliness, patience, and dedication ) of the user. > > Peter Alfke, Xilinx Applications I understand the concern. I for one have been scared off from doing my own routing long ago. But that does not keep me from using the parts. The scary part of the A product is the software. Not only can't you manually route the design, you can't even see the routing to know if the software did a good job. You get a single number to describe each route and that is the delay time. I don't think seeing a complex routing picture would scare off users, especially if it is in the third section you described above. BTW, I would recommend that the sections be provided both partitioned and together in a single document. Perhaps you could have three docs, one with just section 1, the next with both 1 and 2 and a third document with all three sections in a single document. It can be very clumsy to browse through multiple documents as you have heard about the current sectioned documents. This way a user always has a good trade off between completeness and size. -- Rick "rickman" 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 URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42588
Peter Alfke wrote: > > Tim wrote > > > One splendid feature of Xilinx data sheets of yore, seemingly now > > out of favor, was the "differences from previous generation" page. > > Taking a leaf out of consumer electronics user guides, perhaps this > > should be "even if you (think) you are an expert, read this" :) > > Thanks, that was my idea, and my doing. > But for almost ten years, nobody (nobody!) ever expressed any appreciation for > it. > Not Marketing, not Sales, and not even the users. The classical question "who > cares?" > Lots of good ideas die when there is no feedback... Because it sound like a "wishlist" already. What about a table with all(?) the differences between the chips of one family ? So one could see in ONE table the differences (like i/o standards in spartan/xl/ii/iie/...) And having the same layout of the table for different families (xc4, spartan, virtex) ? cheersArticle: 42589
Does anybody know, that Xilinx XC2S-50 and XCS30XL need fan(or cooler).
Maciek
Article: 42590The short answer is: These small chips do NOT need a fan or cooler. The long answer is: There is no fixed power consumption in an FPGA. It all depends on the design and the clock rate(s). If you run the whole chip as a gigantic 400 MHz toggling shift register ( which you can do, although it is meaningless), then you will see high power consumption. Some highly pipelined big DSP designs can dissipate >10W, and they need some cooling. But they are in much bigger chips than you have mentioned. Peter Alfke, Xilinx Applications Maciek wrote: > Does anybody know, that Xilinx XC2S-50 and XCS30XL need fan(or cooler). > MaciekArticle: 42591
In article <3CCC26A4.BCCDB647@earthlink.net>, Peter Alfke <palfke@earthlink.net> wrote: >The short answer is: These small chips do NOT need a fan or cooler. > >The long answer is: There is no fixed power consumption in an FPGA. It all >depends on the design and the clock rate(s). If you run the whole chip as a >gigantic 400 MHz toggling shift register ( which you can do, although it is >meaningless), then you will see high power consumption. Some highly pipelined >big DSP designs can dissipate >10W, and they need some cooling. But they are >in much bigger chips than you have mentioned. That sounds like a challange: Can I do a real app on a XC2S-50 which would require a heatsink? :) Actually, probably not. The power estimator suggests that Gb rate encryption requires only 2.5W (XC2S-100, Rijndael, my design), so adding in IO to do a gigabit link-level encryption engine and it would still be fairly low power. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42592
any input here?? -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 42593
A summary sheet listing the deltas (in detail) from the previous family would
probably make a lot of people happy.
Peter Alfke wrote:
> Rick, and others:
> We at Xilinx are very interested in any constructive suggestions how we can
> make our documentation, especially in my case the data sheet, clearer and
> easier to use.
>
> My present idea ( for future data sheets) is a 3-tier hierarchy
> First a couple of pages of bullets and basic tables, device package
> combinations, and even the ordering info.
> Second about 20 pages with a sequence of terse descriptions of every (every!)
> feature, enough for te "normal" user, with extensive references to the third
> section. This second section act as a guide, preventing anybody from getting
> lost.
> The third section then spends as much space as needed to describe the subject
> in detail. That might be a hundred pages for some features, like
> microprocessors or Multi-Gigabit Transceivers.
>
> The information is all there, even today. The problem is finding it...
>
> Peter Alfke, Xilinx Applications
>
> rickman wrote:
>
> > Hal Murray wrote:
> > >
> > > >Thanks for the post Ray. But I understand how the DLL works, at least
> > > >at the top level of understanding. What I don't know is how all the
> > > >clock resources in the chip play together. Somehow I had gotten the
> > > >impression that the DLLs and the clock buffers could be used separately
> > > >to let you route up to 8 clocks around on the chip. It would appear
> > > >that I was wrong.
> > >
> > > The data sheets usually describe the clock distribution resources.
> > > I'm sure it's in there now that you know what to look for.
> > >
> > > Whenever I start working with a chip, I usually spend a lot of time
> > > with the FPGA Editor (XACT?) learning the details of the special
> > > routing resources. That involves iterations of reading the data
> > > sheets, making test cases, seeing what really results... There
> > > are occasional "Ahh. That's what that section was telling me."
> > >
> > > Maybe I work/think at too low a level and should just push the big
> > > green button, but I always end up pushing some timing limit. I'm
> > > not sure how to do that if I don't know what I want the tools to
> > > produce.
> >
> > Yes, that is what I always end up doing. But it takes a lot of time and
> > if the documentation was more clear, this interaction with the graphic
> > tools would not be required to learn the architechture. However you
> > always have the need to learn what the HDL tools are doing with your
> > design. I have never seen a tool that did not need a babysitter.
> >
> > --
> >
> > Rick "rickman" 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 URL http://www.arius.com
> > 4 King Ave 301-682-7772 Voice
> > Frederick, MD 21701-3110 301-682-7666 FAX
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 42594Ok. I'll work on it, and post it here to start with. Peter Ray Andraka wrote: > A summary sheet listing the deltas (in detail) from the previous family would > probably make a lot of people happy. >Article: 42595
I would like to know who invented FlexLM. This product has been in use for a while with some major EDA vendors, and apparently it is providing a very good job of protecting the integrity and use of the products that use it. I am surprised that in this world of breaking codes, someone hasn't broken the FlexLM code. Don't get me wrong. I am very much in favor of protecting the intellectual property rights of companies or people who develop and market products, and I am glad that it hasn't been broken. I did hear about 3-5 years ago that someone in Hong Kong had broken the code on FlexLM, but I then heard that this was incorrect. I salute a product that has protected EDA products for years and has managed to stay unbroken for so long. Simon Ramirez, Consultant Synchronous Design, Inc. Oviedo, FL USAArticle: 42596
Reminds me of Poly-Paks. For those of you who weren't around back then,
Poly-Paks was a company in the 70's that sold cut rate electronics of dubious
origin to hobbyists. For some, the availability of dirt cheap, albeit not 100%
parts can make the difference between playing with this stuff or just reading
about it. When I started playing with electronics, about all a newspaper route
would support was the Poly-Paks specials. Of course in those days, one could
get away with dead-bug construction and still get something working.
Falk Brunner wrote:
> "Johann Glaser" <Johann.Glaser@gmx.at> schrieb im Newsbeitrag
> news:a9q3it$5enur$1@ID-115042.news.dfncis.de...
>
> > Would it be possible to offer medium size and large size parts (like
> > XC2S200, ...) for hobbyists, prototyping (or even production) at a really
> > low price, but with some small errors. E.g. that one or several (of the
> > many available) CLBs are defect.
>
> Come on, the Spartan-II(E)s are really cheap, have a look at
>
> www.nuhorizons.com
>
> even a poor student can afford them. So I really DONT like to play with a
> just partly functioning IC, especially NOT for development. Debugging you
> own mistakes is hard enough..
>
> --
> MfG
> Falk
>
> P.S. There is no real possibility to get single quantities of the fine
> Xilinx parts in germany (for hobby stuff) :-(
--
--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
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 42597Try www.partsminer.com On Fri, 12 Apr 2002 14:27:04 -0700, Peter Alfke <peter.alfke@xilinx.com> wrote: >I tried it, and found it fast and intuitive, but unforyunately almost worthless >since it does not cover the major distributors. >Nice try, but no cigar. > >Peter Alfke, Xilinx Applications >========================== >Petter Gustad wrote: > >> Try >> >> http://findchips.com/ >> >> This will search through several of the distributor sites for you. >>Article: 42598
In article <IE%y8.118703$nc.17199086@typhoon.tampabay.rr.com>, S. Ramirez <sramirez@cfl.rr.com> wrote: >I would like to know who invented FlexLM. This product has been in use for >a while with some major EDA vendors, and apparently it is providing a very >good job of protecting the integrity and use of the products that use it. I >am surprised that in this world of breaking codes, someone hasn't broken the >FlexLM code. Don't get me wrong. I am very much in favor of protecting the >intellectual property rights of companies or people who develop and market >products, and I am glad that it hasn't been broken. Well, partially, not many people actually use such products, so the incentive to break them is low. Secondly, the floating liscence scheme is far less intrusive than others, again, lowers incentive. Finally, most of the applications which USE FlexLM are expensive cad tools, where the people buying them are paying for tech support as much as the tools themselves. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 42599
Ray Andraka wrote > Of course in those days, one could > get away with dead-bug construction and still get something working. http://groups.yahoo.com/group/fpga-cpu/message/1111 (!) Jan Gray, Gray Research LLC
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