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
when i Translate my top level code i get this type of an error ERROR:NgdBuild:604 - logical block 'filtercore' with type 'mac_fir' could not be resolved. A pin name misspelling can cause this, a missing edif or ngc file, or the misspelling of a type name. Symbol 'mac_fir' is not supported in target 'virtex'. can anyone tell me what it is???/ thanks paraagArticle: 54876
Eric - First off, I sympathize. I wish the available schematic-based solutions worked better, too. For that matter, I wish the existing HDL solutions worked better. But the fact remains that more people are using HDLs than schematics. This is in part due to the schematic tools being broken or poorly supported, but mostly due to the fact that most recent college graduates--the people most likely to do detailed FPGA design--know HDLs. (Do they know logic design? That's another, more contentious thread.) And in my case, I made the switch both because the HDL tools are better supported and because I find I can produce designs more quickly; this is quite an admission for someone who'd used schematics for 25 years before making the switch. Xilinx and other vendors will continue to throw development money where they think the users are. And yes, to some degree it is a self-fulfilling prophecy. I'm not trying to convince you, or anyone, that HDLs are inherently superior to schematics; I don't believe that. But the direction the design world is headed in is pretty unmistakable. Bob Perlman Cambrian Design Works On Mon, 21 Apr 2003 12:17:05 -0400, eric - Mtl <notervme@sympatico.ca> wrote: > > >Bob Perlman wrote: >> Hi - >> >> On Sun, 20 Apr 2003 14:20:21 -0400, eric - Mtl <notervme@sympatico.ca> >> wrote: >> >> <stuff snipped> >> >>>Forcing the switch to HDL by making the schematic tool barely usable >>>is a bit like poisoning water supply to increase bottled water sales. >> >> >> Some days it may seem like Xilinx is trying to move people to HDL by >> sabotaging their own schematic capture tool, but I find it hard to >> believe that's actually the case. The reality is a bit more banal: >> companies spend dollars where the customers are, or where they think >> the customers will be. And when customers started voting for HDL with >> their dollars, Xilinx's development dollars followed. >> >Well, "poisoning" certainly was an overstatement ... what about not >changing the filters and just not fixing the filtration plant until >those brave enough to drink it do it at their own risks ... > >> I'll give you a for-instance that has nothing to do with >> HDL-vs-schematics: many years ago I worked for a company that used >> Sun-based Cadence Concept for its board-level schematic capture tool. >> Concept was actually quite a good program, but I made the mistake of >> thinking that if we used it for board-level stuff, it would also make >> sense to use it for FPGA design. I mean, why in the world would you >> ask all your designers to learn both Concept and, say, Viewdraw, when >> they could use Concept for everything? >> >> It turns out that there was a very good reason: the Concept-to-Xilinx >> netlist path didn't work worth a damn. It was bug-ridden and about >> half a year behind the Viewlogic package in supporting new parts. And >> the path from Xilinx schematics to Verilog simulation netlists was >> equally broken. All in all, it was a disaster. >> >> The reason for the problem became obvious sometime later, after I'd >> ordered a copy of Viewdraw and the accompanying netlister for use on a >> set of FPGA designs. The CAE manager forwarded me an invoice for >> maintenance on both the Cadence-to-Xilinx and Viewdraw-to-Xilinx >> interfaces, and here's what I saw: the serial number for the Viewdraw >> netlister was around 1500; the serial number for the Cadence netlister >> was 12. If there are 1500 seats of one tool out there and 12 of >> another, which is getting the greater share of mind and dollars when a >> bug crops up? >> >> From that time on, I've always paid attention not only to whether a >> tool seemed suitable to my needs, but also to whether a significant >> number of other designers were using it. There may be a justification >> for being one of the few and the proud who use a special tool, but >> it'd better be good. If there's a problem with one of the tools I'm >> using, I want a lot of other people to be screaming bloody murder >> along with me. If some of those people work at Cisco, even better. >> >> How many people out there are using the Xilinx schematic capture tool >> on designs meant to generate revenue? How does that compare to the >> number using HDL? If you're using Xilinx's schematic capture tool, >> the answer should matter to you. >> >> I'm not thrilled with all this. Someday, maybe soon, I'll be forced >> to migrate from Verilog to something like SystemC not because it >> offers me some technical advantage, but because that's where the >> design crowd has migrated. Such is the universe we inhabit. >> >> Bob Perlman >> Cambrian Design Works >> >> > >I understand the problem with using a "marginal" tool, but I really >don't think schematics user are so few. Many peoples in this newsgroup >are at or near the leading edge regarding FPGA design. >They are early adopters, and for peoples whose job is to fill up a >XC2V8000 in no time ;-), HDLs certainly are the only way to go. > >But that's not the whole story ... >We don't all use FPGAs to encode video, do massively parallel DSP, >create wire speed TCP/IP routers, wireless relays or ASIC prototypes. >Most peoples, including me, don't do "rocket science" multi million >gates designs. The design I'm working on now fills about 70% of an >spartan II XC2S100 with SIO & async interfaces, Delta Sigma converters, >a memory interface & MMU, dynamic bus sizer, processor interface, LCD >controller, timers, interrupt controller, IO debouncers, infrared >RC5 decoder ... For me, the FPGA is just a part of the design (a >part that's getting bigger these days). > >Electronics designers are a conservative bunch ... give them a tool they >can grasp immediately and you'll get their business. Tell them that they >first need to learn a completely new and somewhat complex language and >you lost them, or at least significantly delayed adoption. > >This is even more the case for CPLD and CoolRunner users. For them, >I really can't see a break even point where the time spend learning >HDL would be compensated by more convenient design entry. >Also note that for CPLDs, the few extra gates a HDL based design will >infer (compared to a schematic based design) can force them to use the >next bigger part, thus adding a significant cost. > >Many applications could benefit immensely from using FPGAs, and still >don't do. Creating a new entry barrier by deprecating the most "natural" >design entry option doesn't seem like a wise move, especially when all >that is required is to debug and fix the existing tool ... > >my 0.02 ... > >Eric.Article: 54877
The datasheet for the Spartan 3 discloses the types of interconnect (single, double, hex, long), but not their capacity. Short of installing the latest tools on another machine here and playing with the FPGA editor (is Spartan 3 in FPGA editor yet?), is there a source for the width of the various interconnect components and (ideally) routing structure? Thanks. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 54878
B. Joshua Rosen wrote: > On Mon, 21 Apr 2003 12:23:21 -0400, Jim Stewart wrote: > > >>rickman wrote: >> >>>Loi Tran wrote: >>> >>> >>>>In article <b7ssbr$5jk$2@hercules.btinternet.com>, "Leon Heller" >>>><leon_heller@hotmail.com> wrote: >>>> >>>> >>>>>"Loi Tran" <leotran@att.net> wrote in message >>>>>news:Rehoa.35691$cO3.2680296@bgtnsc04-news.ops.worldnet.att.net... >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>Has anyone had any success with Webpack 5.2 installation on Windows >>>>>>98? I get to the point where it asks me to check off on approval of >>>>>>their (we >>>>> >>>>>own >>>>> >>>>> >>>>>>yours ass!) license, but the check box is greyed out. So I can't >>>>>>proceed >>>>> >>>>>any >>>>> >>>>> >>>>>>further. >>>>>> >>>>>> >>>>> >>>>>5.2 only works with Win2000 or XP. >>>>> >>>>>Leon >>>> >>>>Thanks to everyone who replied. Crap! If I'd known this I wouldn't >>>>have paid for the CD to be shipped to me from Xilinx in the first >>>>place. >>> >>> >>>It is only *supported* under 2000 and XP. I don't know that they >>>disable it under any other Windows OS. If they did, this would be a >>>silly way to show it! I bet there is something else going on!!! >> >>I'd like to point out again that this policy is seriously broken. >> >>I feel it is an arbitrary decision on the part of Xilinx that will bite >>them in the ass, much like their half-hearted support of schematic >>capture in early versions of webpack. >> >>I'll keep running Foundation 3.1 with Win98 and legacy devices and start >>evaluating other vendors products for new designs. > > > Why should Xilinx support a broken OS like Win98 when Microsoft no longer > supports it? If you feel compelled to use a Microsoft OS then use a > current version like XP or 2K. Because it *isn't* broken for millions of users.Article: 54879
Actually, FPGA_editor does provide all the information, it's just very
difficult to read. Another way to get all the connection information in the
switchbox is to read the JBits API information from Xilinx JBits Package, or
you can
get all the resource by generating a XDL report for certain device. We have a
custom tool which can place and route
and generate the bitstream on Virtex FPGA, you can go to our webpage:
http://www-unix.ecs.umass.edu/~wxu/jbits/
Weifeng
"Nicholas C. Weaver" wrote:
> The FPGA editor isn't really very useful for this. IS there some
> diagram someone knows of which shows all the connectivity in the
> Virtex switchblock?
>
> --
> Nicholas C. Weaver nweaver@cs.berkeley.edu
Article: 54880The fast way explaining all VHDL keywords ... http://www.amontec.com/fix/vhdl_memo/index.htmlArticle: 54881
Bill Hanna wrote: > > I reported all errors to Xilinx. There are a large number of cases > reported. > > I used schematics instead of VHDL because VHDL is inefficent > compared to schematics. > I benchmarked 3 different designs: 10 stage PN code generator, 27 > stage PN code generator and a 32X32 multiplexer. > > The VHDL designs required 40% more gates than the schematic > designs. The schematic design is converted to VHDL primitives by XST. > > I have a 12 channel signal processor design that uses 17,000 > slices. If implement in VHDL it would take 24,000 slices. The added > cost of the higher density device (XC2V6000) would increase the RE > cost by $3.5K per system. For about $4k you could get a copy of Synplify which will generally save you a bunch of area. Add $1K and you have HDL Analyst which can help you find inefficiencies in your RTL. The fact that XST blew your area budget is not an argument against RTL. > > Thanks for your advice and for taking the time to respond. > Bill Hanna >Article: 54882
naveen wrote:
> Hi,
> iam working on "DIAGNOSIS AND FAULT TOLERENCE OF FPGA's"
> in all the papers related to these fields they say that different
> multiple configurations are to b used to deal with the faults on
> FPGA's.
> my questionS ARE
I took Xilinx Virtex FPGA as target here.
>
> 1) HOW TO WRITE A CONFIGURATION FILE?
The configuration file means the bitstream ("samp.bit" or "samp.hex"),
which is generated by Xilinx CAD tools.
>
> 2) WAT ARE THE CAD TOOLS WHICH WRITE THE CONFIGURATION FILES?
There're different tools packages, for example, Xilinx Alliance, the CAD
flow including Mapping, Placement and Routing,
Bitstream generation or Hex file generation. Here is the link for design
flow:
http://toolbox.xilinx.com/docsan/3_1i/data/common/dev/dev.htm
>
> 3) CAN WE EDIT CONFIGURATION FILE MANUALLY?
In theory, you can if you understand the architecture and bitstream
format very well. But it's very difficult. Considering some special
requirements, Xilinx has a package called JBits which are a bunch of
Java classes, each class can program individual resources like
interconnection or logic. So if you understand your design and
architecture, you can just call the JBits API to modify the bitstream!
We have a custom tool for Xilinx device:
http://www-unix.ecs.umass.edu/~wxu/jbits/
>
> 4) HOW CAN I LOCATE CONFIGURATION FILE ON XILINS FPGA's I MEAN
> THE FILE EXTENSION?
>
.bit or .hex are both configuration files, .hex is a format transferred
from .bit.
Good Luck!
Weifeng
>
> THANX IN ADVANCE
> NAVEEN
Article: 54883Hi, rickman wrote: > eric - Mtl wrote: > >>thanks for your answer, I hear your arguments to switch from schematic >>to HDL. As you acknowledge, transition is long and painful until you >>reach the point where you can achieve optimized designs approaching >>the gate count you get using schematics. after going through this you >>are certainly right that the productivity is better. > > > But the conversion does not have to be long and painful. Pay a few > bucks and take a class in the HDL of your choice. Then make a > commitment to do one of your lesser projects in the HDL. I was > convinced to use HDL when I learned it as part of a three day class in a > schematic tool. I quickly realized the potential and did the entire > project in HDL other than the top level. I was a bit too chicken to do > the IOs in HDL, but that is a piece of cake now. > > What you describe probably is somewhere in my future ... I have nothing against HDLs. It's just not what I'm using now, and if that's going to change, I much better like it to be for reasons such as the ones in your post rather than because I've been coaxed toward it by a neglected tool. > [lots of good stuff stripped] >> >>Forcing the switch to HDL by making the schematic tool barely usable >>is a bit like poisoning water supply to increase bottled water sales. > > > You don't know that this is the case, that Xilinx is deliberately > crippling by ignoring problems. But the handwriting *is* on the wall. > When X came out with Virtex, IIRC, they did not provide schematic > support at all, initially. That was a *strong* message. > ... and putting it back was also a strong indication that they made a mistake ! All I'm asking is that they do it right, more choices can't hurt ... When you started using FPGA, if you were only given the choice between learning either Verilog of VHDL before you could even do the "blinking LED" test on a FPGA, wouldn't that have been a show stopper, or at least a big annoyance ? Every day, new peoples think about using FPGA as a way to improve their designs, and most of them have no time and no interest (at least initially) to learn a complete language and a whole new way of doing the stuff they want. Go to embedded design newsgroups and ask them why most of them don't use FPGAs, you'll be surprised to learn how much the tools are cited as a major problem. >(snip) > > If it were easy, then *anyone* could do it! Why do you think you get > the *big* bucks? > If I was enjoying making big bucks doing boring stuff, I might just as well be a lawyer, perhaps specialized in class actions against software companies who gift their users with buggy software ;-) Eric.Article: 54884
In article <3EA425BC.20203@synplicity.com>, Ken McElvain <ken@synplicity.com> wrote: >For about $4k you could get a copy of Synplify which will generally >save you a bunch of area. Add $1K and you have HDL Analyst which can >help you find inefficiencies in your RTL. The fact that XST blew >your area budget is not an argument against RTL. Where can one get a commercial copy of Synplify for $4k? Also, it really depends on what you write as "RTL". -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 54885
Go get some free Verilgo tutorial onlince, spend some time, write some code, try to get famaliar with some tools, then take the class if you want. It takes some time to know verilog well. Kyle Davis wrote: > I am thinking of enrolling myself at Introduction to Verilog at Xilinx. I > really have to know Verilog in order to be get a better chance of get a job > and better grade in my Advanced Digital Design class. Has anyone ever > attended their class? Are Xilinx instructors good? I have to pay all the > tutions from my own pocket so I would like to know weather their teachers > quality is good or not. > Thanks!Article: 54886
On Mon, 21 Apr 2003 12:23:21 -0400, Jim Stewart wrote: > rickman wrote: >> Loi Tran wrote: >> >>>In article <b7ssbr$5jk$2@hercules.btinternet.com>, "Leon Heller" >>><leon_heller@hotmail.com> wrote: >>> >>>>"Loi Tran" <leotran@att.net> wrote in message >>>>news:Rehoa.35691$cO3.2680296@bgtnsc04-news.ops.worldnet.att.net... >>>> >>>>>Hi, >>>>> >>>>>Has anyone had any success with Webpack 5.2 installation on Windows >>>>>98? I get to the point where it asks me to check off on approval of >>>>>their (we >>>> >>>>own >>>> >>>>>yours ass!) license, but the check box is greyed out. So I can't >>>>>proceed >>>> >>>>any >>>> >>>>>further. >>>>> >>>>> >>>>5.2 only works with Win2000 or XP. >>>> >>>>Leon >>> >>>Thanks to everyone who replied. Crap! If I'd known this I wouldn't >>>have paid for the CD to be shipped to me from Xilinx in the first >>>place. >> >> >> It is only *supported* under 2000 and XP. I don't know that they >> disable it under any other Windows OS. If they did, this would be a >> silly way to show it! I bet there is something else going on!!! > > I'd like to point out again that this policy is seriously broken. > > I feel it is an arbitrary decision on the part of Xilinx that will bite > them in the ass, much like their half-hearted support of schematic > capture in early versions of webpack. > > I'll keep running Foundation 3.1 with Win98 and legacy devices and start > evaluating other vendors products for new designs. Why should Xilinx support a broken OS like Win98 when Microsoft no longer supports it? If you feel compelled to use a Microsoft OS then use a current version like XP or 2K.Article: 54887
I guess you may need to call some low level JBits API to program the PIPs. I
have worked with Tri-state buffer in IOB, We've a custom tool which can
generate the bistream for a Xilinx FPGA communicates with DSP through 32-bits
I/O bus.
You can find more details in this page:
http://www-unix.ecs.umass.edu/~wxu/jbits/
Florian-Wolfgang Stock wrote:
> Hello,
>
> if I have verilog-lines for a Tristate inout like this:
>
> inout [32:0] DATA;
> assign DATA = WRITE ? DATAOUT : 32'hzzzzzzzz;
>
> how would I do this in JBits? I work with the Board-Class, and
> my code looks like this:
>
> int tmp=board.addInput("DATAIN",diBus);
> int tmp2=board.addOutput("DATAOUT", doBus);
>
> Both (DATAIN and DATAOUT) have in the ucf-file, which I parse with
>
> board.implement(0,"myucffile.ucf");
>
> the same LOCs. I try to connect the Tristate-Line with this command:
>
> board.setTristate(tmp2, triNet);
>
> and with this command I am not sure, because the javadoc (and the
> tutorial too) is at this functions not very helpfull. Are there any
> more calls necessary for instantiating the Tristateline? And what
> signal enables the z's? Must the triNet be 1 or 0? I am thankful for
> any help (or at least a good hint where I can look for it).
>
> Thanks in Advance
> Florian
> --
> int m,u,e=0;float l,_,I;main(){for(;1840-e;putchar((++e>907&&942>e?61-m:u)
> ["\t#*fg-pa.vwCh`lwp-e+#h`lwP##mbjqloE"]^3))for(u=_=l=0;79-(m=e%80)&&
> I*l+_*_<6&&26-++u;_=2*l*_+e/80*.09-1,l=I)I=l*l-_*_-2+m/27.;}
Article: 54888Jim Stewart wrote: > > I'd like to point out again that this policy is seriously broken. > > I feel it is an arbitrary decision on the part of Xilinx that will > bite them in the ass, much like their half-hearted support of > schematic capture in early versions of webpack. > > I'll keep running Foundation 3.1 with Win98 and legacy devices > and start evaluating other vendors products for new designs. Before you give up on installing Xilinx, did you find viewing the "agreement" would let you install the software? I can't imagine that Xilinx would *block* you from using this under another OS. As to the Xilinx "broken" policy, I can understand why they do this. When a vendor sells a few thousand copies of software and gives away a great many more, they need to cut their costs anywhere they can. Eliminating three out of five versions of Windows is a big savings to them. Heck I was ticked when they dropped Win 95, but that was a major motivator for me to upgrade to Win2000 and I am ***SO*** glad I did. My system is yards more stable and I can actually leave it running for weeks without problem (well, more than a week anyway). I expect now most of my problems are poor apps. This includes Microsoft's. I run Visio a lot and find that it will crash for no reason. Just often enough that it is a problem, but infrequently enough that I get out of the habit of saving every five minutes. This can get old very quickly. My suggestion: get over being ticked at Xilinx and find a way to upgrade your OS to Win2000 or even XP. Or maybe this is the nudge you need to switch to Linux! Before I will switch to XP, I will give Linux a serious go. Win2000 will be my last Microsoft OS. -- 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: 54889
Hi, We've exactlly the tool you'll need. Here is the webpage:
http://www-unix.ecs.umass.edu/~wxu/jbits/
We've developed a VPR for Virtex will will generate the placement and
routing, also we've a JBits tool which can
generate a bistream or XDL file. Please evaluate our tool, your feedback
will be appreciated!
By the way, you can implement your own placment and routing algorithm
if you want, the only thing need to be kept
untouched is the routing graph and the outout format.
Weifeng
Kostas wrote:
> Hi,
>
> I use the T-VPack and VPR academic tools from Toronto University in
> order to make the placement and routing of simple designs. I have the
> problem that there is no bitstream tool available from this team.
>
> I have found the JBITS from XILINX, that also use a modified version of
> VPACK and VPR. The problem is that tools from Xilinx supports Virtex
> FPGAs and not the FPGA architecture that supported by Toronto.
>
> Has anyone any idea about how can i make the bitstream file ?
>
> Thanks
Article: 54890I can find brief datasheets listing pinouts. Are there any more detailed specs on how to take an image of the chip, and upload it? For ISP, by the end user, where a programming device will not be available. -- http://inquisitor.i.am/ | mailto:inquisitor@i.am | Ian Stirling. ---------------------------+-------------------------+-------------------------- "The theory of everything falls out trivially." -- Etherman, sci.physics kook.Article: 54891
Yes. There's tons of documentation and examples and application notes on the Xilinx web site. Strangely enough, there's even documentation on how to do it on the Altera web site too. On Mon, 21 Apr 2003 18:20:02 +0000 (UTC), Ian Stirling <root@mauve.demon.co.uk> wrote: >I can find brief datasheets listing pinouts. >Are there any more detailed specs on how to take an image of the chip, and >upload it? >For ISP, by the end user, where a programming device will not be available.Article: 54892
I got nailed on an early Virtex design where the 1x and 2x clocks were sourced
by the same DLL. Several factors contributed:
- the 1x clock was very lightly loaded while the 2x clock was heavily loaded,
- There was fair amount of jitter on the clock input (>300ps IIRC),
- There was heavy output switching on pins adjacent to the clock input pin (adds
to jitter at DLL clock input)
- the failing nets were on direct flip-flop to flip-flop connections (no LUT) on
FF's that were floorplanned to be adjacent.
- static timing indicated no setup or hold violations.
The combination of the jitter (which with input jitter barely in spec plus
jitter introduced by output current modulation of input thresholds was likely
out of spec), highly skewed loading (not convinced this is a real factor), and
the absolute minimum flip-flop to flip-flop delay conspired to bite us where it
counted. Since then, we have as a policy treated the 1x and 2x clock domains
with utmost care to make sure the receiver is not sensitive around the
transmitter's active edge. I suspect that if you have no direct connects
between adjacent slices at the clock domain boundary, you won't have a problem.
Eric Pearson wrote:
> Hi John....
>
> Static timing analysis must take into acount both setup and hold.
> You comments about minimum time (hold time) are true, however don't
> be too conservative. The delays of concern do track at a macroscopic level
> as they have common voltage, process, and temperature. Don't forget
> that even for a single clock case you still have hold time issues in
> the face of clock skew within the distribution tree.
>
> The key question is how will you verify that the design will work
> over all situations.
>
> Are you sure those 'others' who have not been able to get their systems
> operating with two clocks did any sort of hold time analysis? There are
> yet 'others' who sucessfully use 1x/2x domain crossing again and again
> using full setup and hold time analysis.
>
> Good luck with your design. You are approaching it with the right
> frame of mind.
>
> Eric
>
> "John_H" <johnhandwork@mail.com> wrote in message
> news:3E9EB04A.3090705@mail.com...
> > I don't belive this will produce 100% results. Using the same DLL is a
> > requirement to having a chance of working at the high speeds.
> >
> > The "same" edge is not necessarily guaranteed to be sourced from the
> > same input edge through the delay taps to the output. I'd like it if
> > they were such that input jitter won't produce skew between like edges.
> > Without details on the DLL innerds, I can't make that call so I err on
> > the side of caution.
> >
> > The clock skews are accounted for in the static timing analysis for
> > worst case delays. If the longest Tcko, the longest net delays, the
> > worst case Tsu and clock skew don't exceed your budget, the static
> > timing analysis declares that you're "golden." Unfortunately, the
> > "minimum" timing isn't specified. The skew between clocks can result in
> > the earlier clock producing a result before the destination register
> > (and associated clock) is clear of its setup/hold window. We have a
> > guarantee for the same-clock situation where the clock skews are in the
> > range of 10s of ps but not for the different-clock situation where that
> > spread is easily in the 100s of ps.
> >
> > Other users have been bitten by crossing the 1x and 2x domains on the
> > "common" rising edge so I'm trying to avoid that assumption that the
> > edges are safely coincident.
> >
> > . . .
> >
> > I need to revisit my thoughts to see if I considered using latches
> > instead of registers for the negedge x2 sampling of the x1 domain. I
> > might sneak out 100s of ps with latches rather than registers.
> >
> >
> >
> > Eric Pearson wrote:
> > > Hi John...
> > >
> > > Can't you generate both clocks from the same PLL so the edges stay
> > > together, and use static timing analysis to handle any clock tree
> loading
> > > skews?
> > > I usually do anything to avoid "clock-the-clock" situations.
> > >
> > > Eric
> > >
> > > "John_H" <johnhandwork@mail.com> wrote in message
> > > news:3E9C1B1F.8020305@mail.com...
> > >
> > >>Thanks, Ray.
> > >>
> > >>I used the RLOCs and double-checked the routing to make sure the numbers
> > >>were "smallest" and still found myself with almost no margin left over
> > >>for input jitter tolerance. The Tcko and any of the Tceck or Tdick or
> > >>Tsrck values along with the shortest net I could muster left the 1.8 ns
> > >>for 1/4 clock at the hairy edge. I was hoping there was an innovative
> > >>approach to avoiding the 1.8ns requirement for a 7.2 ns x1clk.
> > >>
> > >>- John_H
> > >>
> > >>Ray Andraka wrote:
> > >>
> > >>>John, You are right ot be concerned about skew between the 1x and 2x
> > >>
> > > clocks. If
> > >
> > >>>you control placement and are clever about getting direct flip-flop to
> > >>
> > > flip-flop
> > >
> > >>>connections you can manage to do what you are describing using a
> falling
> > >>
> > > edge
> > >
> > >>>sensitive FF in the 2x domain to capture the 1x clock, then take the
> > >>
> > > output of
> > >
> > >>>the falling edge FF and feed it to a rising edge FF in the 2x domain to
> > >>
> > > time
> > >
> > >>>align the resulting CE with the 2x clock rising edges. The CE is
> > >>
> > > probably
> > >
> > >>>inverted WRT to what you wanted at that point, in which case an
> > >>
> > > additional
> > >
> > >>>rising edge FF will put it right without adding any logic delays in the
> > >>
> > > critical
> > >
> > >>>timing around the neg edge FF. You'll need to use primitives with
> RLOCs
> > >>
> > > on them
> > >
> > >>>to keep the timing tight, and with v4.2 and later tools you need to
> make
> > >>
> > > sure
> > >
> > >>>you put the time constraints in for each connection in order to keep
> the
> > >>
> > > router
> > >
> > >>>honest (3.3 did a good job of finding the direct connect without having
> > >>
> > > an
> > >
> > >>>explicit time constraint).
> > >>>
> > >>>John_H wrote:
> > >>>
> > >>>
> > >>>
> > >>>>Thanks for the message last week, Eric - my newsreader at work isn't
> > >>>>100% and I had to read/respond at home.
> > >>>>
> > >>>>Your comment about only needing two flops is accurate as long as the
> > >>>>designer can trust that the x1clk and x2clk domains will always work
> > >>>>together as we'd expect where the rising edges are coincident. The
> > >>>>reality is that those two edges may be separated by some 100s of ps
> > >>>>since the clock net loading can be different between the two domains
> and
> > >>>>input clock jitter to the DLL may translate to the two domains at
> > >>>>different cycles. THe former problem is known, I'm only speculating
> on
> > >>>>the latter. Bottom line: I can't depend on the two domains to play
> nice
> > >>>>at the common rising edge, hense the nead to offset things by 1/4 the
> > >>>>x1clk (or 1/2 th x2clk).
> > >>>>
> > >>>>Any further thoughts are appreciated.
> > >>>>
> > >>>>- John_H
> > >>>>
> > >>>>Eric Pearson wrote:
> > >>>>
> > >>>>
> > >>>>>"John_H" <johnhandwork@mail.com> wrote in message
> > >>>>>news:T9Hka.9$716.2363@news-west.eli.net...
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>Has anyone figured out a nice, clean method to track which phase of
> a
> > >>>>>
> > >>>>>Xilinx
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>DLL's 1x clock corresponds to a 2x clock cycle? One 2x rising edge
> > >>>>>>corresponds to the 1x rising edge, the other 2x rising edge
> > >>>>>
> > > corresponds to
> > >
> > >>>>>>the 1x falling edge.
> > >>>>>>
> > >>>>>>When I start getting up in frequencies, the ability to use the 1x
> > >>>>>
> > > clock
> > >
> > >>>>>and
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>inverted 1x clock to generate two signals that I can XOR for a phase
> > >>>>>
> > > is
> > >
> > >>>>>>compromised. It's not inherently safe to use the 1x edges and 2x
> > >>>>>
> > > rising
> > >
> > >>>>>>edges as "effectively" the same edge due to clock skews and input
> > >>>>>
> > > jitter
> > >
> > >>>>>>issues. Using the falling edge of the 2x clock to sample the 1x
> > >>>>>
> > > generated
> > >
> > >>>>>>signals works, but at the 1/4 period timing budget is too tight at
> the
> > >>>>>>frequencies I'm working.
> > >>>>>>
> > >>>>>>For those who are Verilog friendly, the code here shows how I would
> > >>>>>>"normally" extract the phase without running a clock through a LUT.
> > >>>>>
> > > The
> > >
> > >>>>>>"negedge x2clk" is where the timing gets tough since the
> > >>>>>
> > > Tcko+Tnet+Tick is
> > >
> > >>>>>a
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>little over the 1/4 period of my x1clk.
> > >>>>>>
> > >>>>>>always @(posedge x1clk) posTog <= ~posTog;
> > >>>>>>always @(negedge x1clk) negTog <= posTog;
> > >>>>>>always @(negedge x2clk) rawPhase <= posTog ^ negTog;
> > >>>>>>always @(posedge x2clk) phase <= rawPhase;
> > >>>>>>
> > >>>>>>Is there a cleaner way to figure out the which half of the x1clk I'm
> > >>>>>
> > > in?
> > >
> > >>>>>>Thanks,
> > >>>>>>- John_H
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>It really only takes 2 flops working on rising edge.
> > >>>>>
> > >>>>>always @(posedge x1clk) Toggle <= ~Toggle;
> > >>>>>always @(posedge x2clk) Delayed <= Toggle;
> > >>>>>assign Phase = DelTog ^ Tog;
> > >>>>>
> > >>>>>Eric
> > >>>>>
> > >>>>>
> > >>>>
> > >>>--
> > >>>--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
> > >>>
> > >>>
> > >>
> > >
> > >
> >
--
--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: 54893You could pre-add to improve processing bandwidth: (Zx + Zn-x).bx This means 128 Complex multiplies and adds every 30MHz ... about 4Gigs Performance... I would say that this one is challenging :-) Not sure if you will pull it off even with a big one. I would propose you use a big Stratix - with its inbuilt MACs you might have a show. Dynamic update ... Are you saying you have to be able to update coefficients while filter running? Dont forget the associated distortion if this takes longer than a sample to do. All memories can be configured as dual port ... if you dont need update in one sample then its easy. If you do ... then there are lots of memory ESBs on the Stratix so you can mux them - providing a way to update all coefficients at the same time. This would slow the whole thing down due to muxes. "Arthur Herbert" <herbert.arthur@caramail.com> wrote in message news:3EA3B77A.1020305@caramail.com... > Hi - > > I would like to implement a 256 tap complex FIR filter. > It should run at 30MHz and latency should be lower than 200ns... > Moreover, the coefficients should be updatable 'live', ie, without > interrupting the filtering process... > Seems to be quite a hard task ! > Does anyone have an idea of FPGA implementation ? > What kind of circuit should be used ? > How many CLB/LE would it take ? > Thanks in advance > > Arthur >Article: 54894
I work for a volume manufacturer using 1C6. Take your price below and * 1/3 would be more accurate. I am interested in watching what Xilinx are going to do to compete. Cheers. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:3E9F6D62.B9B9BC2B@yahoo.com... > Steve Knapp wrote: > > > > The primary advantages of the Spartan-IIE family in the 256-ball BGA > > package is that you can choose between six devices already in volume > > production that are readily available in a footprint-compatible > > package. Spartan-IIE also offers lower price points for 182 I/O pins. > > Plus, Spartan-IIE devices offer distributed RAM and shift-register > > capabilities within each logic cell, which can dramatically increase > > logic effectiveness by a factor of 16X! Likewise, Spartan-IIE has > > internal bi-directional bussing capability without consuming any logic > > cells. Furthermore, Spartan-IIE supports PCI up to 64 bits wide at 66 > > MHz. > > > > The five pin-compatible Spartan-IIE devices in full production include > > the following. > > I think your comparison is a bit uneven. Yes, the Xilinx parts seem to > split the range up into finer pieces. But the prices are not > necessarily better. In the largest size the Altera part is more > expensive, but it also has about 50% more LEs than the XC2S600E. > > So the Xilinx parts have one size, the XC2S150E, that gives a > significant price advantage over the Cyclone parts. But then this is > based on "list" prices and means nothing once you start wheeling and > dealing with your disti. > > > Xilinx LUT+FF pairs Altera LEs > * XC2S50E 1,536 $ 16.61 > * XC2S100E 2,400 $ 24.47 EP1C3 2,910 $16.60 (T144) > * XC2S150E 3,456 $ 26.84 EP1C4 4,000 $??? > * XC2S200E 4,704 $ 31.29 > * XC2S300E 6,144 $ 48.01 EP1C6 5,980 $33.20 > * XC2S400E 9,600 $ 91.52 EP1C12 12,060 $87.00 > > * XC2S600E 13,824 $152.90 EP1C20 20,060 $222.00 > (FG456) (FT400) > > For a minute I thought you had made a mistake on the logic cell count > until I remembered that the Xilinx data sheet got "creative" on what > they call a logic cell. Someone in marketing should be shot for that > one. Gate counts are pure myth. But I always thought I knew what a > logic cell was. > > > > The six Spartan-IIE devices in the 256-ball BGA package range in price > > from US$16.61 to $91.52 in 24-99 quantity, depending on speed grade > > (SOURCE: www.avnetmarshall.com). Pricing in the U.S. is also available > > via www.insight.com and http://www.nuhorizons.com. Nearly all > > device/package combinations are in stock at the distributor. The wider > > range of densities provides finer granularity on logic vs. I/O. If your > > design is primarily I/O, then prices start as little as $16.61. > > > > Compare this to only two Cyclone devices in this package, ranging in > > price from US$33.20 to $174 in 24-99 quantity, depending on speed grade > > (SOURCE: www.arrow.com). All devices show 6 weeks lead-time. > > Maybe only two in *that* package. But Altera's approach is to use > packages with a compatible footprint. So you can buy the 1C6 and the > 1C12 in the F256 package and move up to the 1C20 in the F324 or F400 > package in a compatible footprint. Design this in up front and you > won't have to redo your PCB. Or you can move *down* to the 1C4 in the > F324 or F400 package and get up to 301 IOs! > > > > Spartan-IIE is manufactured on 0.15u (150 nm) technology using 300 mm > > wafers. Certainly, 0.15u is larger than Cyclone's 0.13u technology, so > > Cyclone has roughly a 25% die size advantage at comparable logic > > densities. However, Cyclone is manufactured on 200 mm wafers. The 300 > > mm wafer manufacturing advantage provides Spartan-3 with about a 30% > > cost saving. > > But that only matters if it shows up in the prices above, and it > doesn't. > > > > If designing for applications going to production early next year and if > > you are considering changing FPGA families, you should also consider the > > recently announced Spartan-3 family. Spartan-3 is manufactured on > > advanced 90 nm (0.09u) technology, offering about a 50% area advantage > > over 0.13u. Software support is already available in ISE 5.2i, but I > > recommend downloading the latest service pack for recent feature > > upgrades. > > > > http://www.xilinx.com/xlnx/xil_sw_updates_home.jsp > > > > There are three footprint-compatible Spartan-3 devices planned in the > > 256-ball BGA package, as shown below. The XC3S1000 recently started > > sampling. There are 173 I/O in the 256-ball BGA package for Spartan-3. > > Spartan-3 advantages over Cyclone include larger block RAM size (18Kb > > vs. 4Kb), embedded 18x18 multipliers, four digital clock managers (clock > > frequency synthesis, de-skewing, clock correction, etc.), more supported > > I/O standards, distributed RAM/shift-register capability, dedicated DDR > > registers, wide multiplexers, more devices, more I/O, and higher device > > densities. > > > > * XC3S200 (3,840 LUT+FF pairs, planned) > > * XC3S400 (7,168 LUT+FF pairs, planned) > > * XC3S1000 (15,360 LUT+FF pairs, sampling) > > > > --------------------------------- > > Steven K. Knapp > > Applications Manager, Xilinx Inc. > > Spartan-3/II/IIE FPGAs > > http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=Spartan-3 > > E-mail: steve.knapp@xilinx.com > > --------------------------------- > > > > CB wrote: > > > > > > comparing the spartan2e and cyclone component lines in the 256 pin bga > > > packages , can anyone please tell me advantages in going with the > > > cyclone versus staying with the spartan2e , i don't care minor > > > differences in the ram and i/o but i am interested in significant > > > advanges the cylcone may have, thank you in advance > > CB, I hope the price/size comparison above helps. The Altera parts seem > to be a better buy for the size. Unless you need the lowest priced > part, you seem to get more bang for the buck. If you go with a smaller > package, you still get a better deal with the Altera. Also, you have a > higher range chip to choose with Altera, 1C20. > > -- > > 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: 54895
rAinStorms wrote: > > I work for a volume manufacturer using 1C6. > > Take your price below and * 1/3 would be more accurate. > > I am interested in watching what Xilinx are going to do to compete. I don't understand what you are saying. Are you saying that Altera sells their parts in volume for a third the price listed below and Xilinx doesn't? It has always been my understanding that you can get significant price reductions from nearly *any* chip maker if you are using large quantities. Why would Xilinx be any different? I am quite certain that Altera was looking at a Xilinx Spartan II price sheet when they set the Cyclone *list* prices. The real price for quantities *always* depends on their real costs of manufacture, or even their *future* cost of manufacture. They can take a loss on the parts now knowing that they will be able to get their production costs down over the life of *your* product and end up turning a profit. Of if nothing else they will even buy a socket to keep the competition out of your shop! But this is all based on volume. -- 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: 54896
Christopher Fairbairn <ckf13@student.canterbury.ac.nz> wrote: : 5) I copied msvcirt.dll over from my Win2k machine and placed it in : ~/c/windows/system32 If you use Win2k version dlls, set the wine version to the version of the dlls you use. And use the corresponding MSVCIRT/MSVCRT combo. But I wonder why the Xilinx installation doesn't deposit the needed MSVC*RT.dll? Something in wine is probably still not right in that concern... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 54897
rAinStorms wrote: > You could pre-add to improve processing bandwidth: (Zx + Zn-x).bx > This means 128 Complex multiplies and adds every 30MHz ... about 4Gigs > Performance... The FIR to be designed has no symetric coefficients (if this is what you suggest) > > I would say that this one is challenging :-) > > Not sure if you will pull it off even with a big one. > > I would propose you use a big Stratix - with its inbuilt MACs you might have > a show. Might be. Do you think that muxing could help spare some CELLs, i mean having a set of 32 Multiplier blocs each processing 8 times 30MHz would 'only' use 2 big stratix... innit ? > Dynamic update ... Are you saying you have to be able to update coefficients > while filter running? Dont forget the associated distortion if this takes > longer than a sample to do. Yes. Do you have some references about that sort of distorsion ? > All memories can be configured as dual port ... if you dont need update in > one sample then its easy. > If you do ... then there are lots of memory ESBs on the Stratix so you can > mux them - providing a way to update all coefficients at the same time. This > would slow the whole thing down due to muxes. > Thanks a lot for your advices, Arthur ;) > > "Arthur Herbert" <herbert.arthur@caramail.com> wrote in message > news:3EA3B77A.1020305@caramail.com... > >>Hi - >> >>I would like to implement a 256 tap complex FIR filter. >>It should run at 30MHz and latency should be lower than 200ns... >>Moreover, the coefficients should be updatable 'live', ie, without >>interrupting the filtering process... >>Seems to be quite a hard task ! >>Does anyone have an idea of FPGA implementation ? >>What kind of circuit should be used ? >>How many CLB/LE would it take ? >>Thanks in advance >> >>Arthur >> > > >Article: 54898
B. Joshua Rosen wrote:
>
> Why should Xilinx support a broken OS like Win98 when Microsoft no longer
> supports it? If you feel compelled to use a Microsoft OS then use a
> current version like XP or 2K.
If they don't support it, how is it that I can go to any
local computer retailer and pick up a copy of 98SE--at the
same price as XP on the shelf next to it?
-=Dave=-
Article: 54899>Before you give up on installing Xilinx, did you find viewing the >"agreement" would let you install the software? I can't imagine that >Xilinx would *block* you from using this under another OS. I would if I could, but the policy isn't even displayed. >My suggestion: get over being ticked at Xilinx and find a way to upgrade >your OS to Win2000 or even XP. Or maybe this is the nudge you need to >switch to Linux! Before I will switch to XP, I will give Linux a >serious go. Win2000 will be my last Microsoft OS. The reason why I'm still using Windows 98 is because I swore I would never buy anything from M$ or M$ related again. You can stop groaning now (and thinking I'm a cheapskate). I would pay for anything that's proven itself. The only thing that Microsoft has proven is that it produces an inferior product and claim superiority. I stop counting the number of times I've cursed and sworn at a computer running Microsoft product (at work and at home). But Webpack is the one thing I'd like to use and it isn't supported under Linux except with WINE (which I don't want to USE). LT
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