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 would rather to use Vhdl or other languages, I think Using language in taem works is much better than the Schematic map.If you team partergive you a big schematic map, how can you know what he do and what he want to do? But in vhdl language, it's easy!Article: 37901
Greetings all, What's the availability of production VirtexII silicon (ie, not -ES parts) like? Our suppliers are telling us that they can't get non -ES silicon, but since VirtexII has been in the market place for nearly a year now, I can't believe production silicon isn't out there. Is our supplier being slack or is Xilinx just having a hard time getting VirtexII to work properly? -- David Miller, BCMS (Hons) | When something disturbs you, it isn't the Endace Measurement Systems | thing that disturbs you; rather, it is Mobile: +64-21-704-djm | your judgement of it, and you have the Fax: +64-21-304-djm | power to change that. -- Marcus AureliusArticle: 37902
I had used the xc2s100( spartan 2) device, and I use the core generator make a fifo, And I do the time simulation, when it works at 80 Mhz, it made some mistake, but when it works at 50Mhz, it' correctly! So I think perhapes you should think about the frequency that you works on, just try to lower the frequency!Article: 37903
Perhaps you don't use that pin in your design, or that pin has no effect on the output!Article: 37904
There were, sigh, several little things to fix. And at the going price for a mask set ( multi-$100k) we do a lot of simulations, and manufacturing takes many weeks or months. I think we all agree that these chips are quiet complex, almost as complex as software ;-) Production version availability depends on the device type. They come out widely staggered. Check with your Xilinx rep or distributor. They are as anxious as all of us to satisfy your need. And, as you may know, -ES is not that bad... Peter Alfke David Miller wrote: > Greetings all, > > What's the availability of production VirtexII silicon (ie, not -ES > parts) like? > > Our suppliers are telling us that they can't get non -ES silicon, but > since VirtexII has been in the market place for nearly a year now, I > can't believe production silicon isn't out there. > > Is our supplier being slack or is Xilinx just having a hard time getting > VirtexII to work properly? > > -- > David Miller, BCMS (Hons) | When something disturbs you, it isn't the > Endace Measurement Systems | thing that disturbs you; rather, it is > Mobile: +64-21-704-djm | your judgement of it, and you have the > Fax: +64-21-304-djm | power to change that. -- Marcus AureliusArticle: 37905
Ed, if you have many years of experience with TTL, ECL etc, then you are well-prepared for designing with FPGAs. It's really just normal logic design with slightly different constraints. And most likely a much higher level of complexity, like using thousands of flip-flops. When I started this thread, I objected to very basic questions that should have been clarified in college, or by reading any one of many textbooks. Merry Xmas! Peter Alfke ========================================= Ed Ngai wrote: > But for many years all I ever dealt w/ was TTL, CMOS, ECL, GALs, some linear. > And for maybe 16 years I 'never' touched upon a need for implementing FPGAs, > using design tools, etc. Because of a jelly doughnut in 1994 I went into a > Computer Literacy bookstore on Steven Creek and bought the FPGA Workbook by > Dave Bout, Xess Engr. My 1st experience w/ an Intel FPGA, which Intel > obsoleted. > I don't have a stacked bookshelf for FPGA written material. I say if it's in > a book somewhere, then post the book reference. Is it that big of a deal to > post > a reference? > > Ray Andraka wrote: > > This is part of the problem. Too many people are "learning" hardware design and VHDL > > at the same time. I am firmly of the opinion that folks need a solid digital hardware > > background before learning VHDL. Learning both at the same time leads to a host of > > design problems caused by not understanding how the VHDL code is mapped into hardware, > > as well as the inevitable timing problems that come up with code written as though it > > was for a software target. FPGA design is digital hardware design no matter what kind > > of fancy tools you put in front of it. If you don't design with hardware in mind, > > you'll soon find out about it in the lab. > > > > Ed Ngai wrote: > > > > I'm not a hot shot FPGA user yet. In fact it took me 4 to 6 months to find > > > out how to do a 4 to 1 multiplexer. I had to go to 2 book stores, look > > > all over the web. Sent email to Xilinx. I'm not going to school, but I want > > > to learn how to work w/ FPGAs. I finally bought 2 books, The VHDL handbook and > > > VHDL. > > > > If it's in a book somewhere, then how about posting these book references? > > > > Remember you have been doing this for a long time and I'm reading a chapter > > > maybe every month ? > > > > > Let's use our "bandwidth" for more complex and perhaps controversial questions > > > > that are not explained in textbooks and data books. > > > > Peter Alfke, Xilinx Applications > > > How do I get the Foundation CDs from Xilinx? > > > --Ray Andraka, P.E. , President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email ray@andraka.com , http://www.andraka.comArticle: 37906
Tell me about your FIFO. Does it have many "bells and whistles" i.e. complicated features like "Half-full" etc? Otherwise I would not accept anything less than 100 MHz. I consider this a challenge, FIFOs have been my "hobby" for >30 years now. Let me know! Peter Alfke, Xilinx Applications ===================================== ZhengLin wrote: > I had used the xc2s100( spartan 2) device, and I use the core generator make a fifo, And I do the time simulation, when it works at 80 Mhz, it made some mistake, but when it works at 50Mhz, it' correctly! > So I think perhapes you should think about the frequency that you works on, just try to lower the frequency!Article: 37907
The manual tell me that the fifo can be run up to 200Mhz, but it's in the chip, It'can't be output at so high frequency;and in my design, I use the fifo as part of the Utopia L2'buffer, it has much logic to do before read or write the fifo, so it can't work so high; Thanks for your attention!Article: 37908
On Mon, 24 Dec 2001 06:10:28 GMT, Peter Alfke <palfke@earthlink.net> wrote: >There were, sigh, several little things to fix. And at the going price for >a mask set ( multi-$100k) we do a lot of simulations, and manufacturing >takes many weeks or months. >I think we all agree that these chips are quiet complex, almost as complex >as software ;-) I am glad quiet complex. If they were loud and complex, I guess we would've been in a lot more trouble :-). Actually having been struggling with a 400uX420u .25u standard cell digital macro running at 500 MHz for the last three weeks, I should be more respectful. It is amazing how bad the generic standard cell libraries are and how good a virtex-ii is. Muzaffer Kal http://www.dspia.com DSP algorithm implementations for FPGA systemsArticle: 37909
Hi, I will like to know how the readers of this newsgroup think of
including clock skew for setup time analysis?
I am working on a PCI IP core which with various suggestions from the
readers of this newsgroup, I was able to improve setup timings (Tsu)
through reduction of logic levels (reduction of levels of LUTs).
I am using ISE WebPack 4.1 and targeting Spartan-II 150K system gate
part for my PCI IP core.
In ISE WebPack when I ran TRCE to generate a timing error report, the
timing report for setup time includes clock skew occurring, and this
clock skew time subtracts some time off the data path delay (data path
delay = gate delay + routing delay) which becomes total or final delay,
and the worst time here is shown in the timing summary section.
However, if I think carefully about the timing data shown in the report,
the temperature assumed here is 85 degrees celsius, and since
semiconductor devices have less delays in a lower temperature, at room
temperature (20 degrees Celsius) the clock skew will likely be much less
than what the report suggests, and even lower at a freezing temperature
(0 degrees Celsius, the lowest temperature commercial package version of
Spartan-II is guaranteed to function).
Yes, I do realize that at a temperature lower than 85 degrees Celsius,
the gate delays for LUTs and FFs will also decrease, therefore even if
the clock skew decreases that shouldn't cause a major problem, however,
no one really knows which one will decrease faster.
Another problem I can think is that in the case of Xilinx
devices, several Xilinx employees have written publicly in this
newsgroup (I know those are their own opinions, and not necessarily the
company's official position on the issues being raised) that whether or
not it is a different speed grade, all the chips come from the same
silicon wafer.
That will mean that in the case of Virtex, speed grade -4, -5, or -6
devices come from the same silicon wafer.
I knew nothing about FPGAs two years ago, but from what I hear, Xilinx
first came out with Virtex speed grade -4 in 1998, and later got speed
grade -5 and -6 out (I don't know the exact release date of those two
speed grades. I will be interested to hear when they started to ship).
Likely most chips manufactured back in 1998 ran only at speed grade -4,
but as Xilinx improved the speed of Virtex through circuit and
manufacturing improvements, it was able to pick chips that will run at
speed grade -5 or -6.
However, there are customers who designed products in the days of Virtex
speed grade -4, so Xilinx still has to supply Virtex speed grade -4 to
the market.
The concern I have here is that even though the chip is marked as a
Virtex speed grade -4, isn't it possible that chip could have been
marked as a speed grade -6 device because it was manufactured recently?
(let's say in 2001)
If so, won't the clock skew assumption made during the setup time
analysis be off for such Virtex speed grade -4 device, perhaps by 1ns to
2ns depending on the device size?
I am not criticizing Xilinx for bin splitting devices, but I think it
seems risky to use maximum clock skew during setup time analysis.
Are there any ways to disable using maximum clock skew from being used
in MAP/PAR/TRCE/TimingAn?
Thanks,
Kevin Brace (don't respond to me directly, respond within the newsgroup)
Article: 37910Ed Ngai wrote: > But for many years all I ever dealt w/ was TTL, CMOS, ECL, GALs, some linear. > And for maybe 16 years I 'never' touched upon a need for implementing FPGAs, > using design tools, etc. Because of a jelly doughnut in 1994 I went into a > Computer Literacy bookstore on Steven Creek and bought the FPGA Workbook by > Dave Bout, Xess Engr. My 1st experience w/ an Intel FPGA, which Intel > obsoleted. I've finally found him - the other FX780/880 user! In fact Intel didn't obsolete them they sold them to Altera. I believe Altera just wanted access to the Flash technology and so they, Altera, obsoleted them 18 months or so later. By then, of course, the XC95K devices were on stream ... What used to impress me about these parts was not the silicon itself - though we have Intel to thank for JTAG ISP - but how incredibly good the fitter was at making the best of the device's meager resources. Used to take forever to run on an i486-66 but it got there in the end, mostly.Article: 37911
ZhengLin <zdzlin@163.com> wrote in message news:<ee73e5f.0@WebX.sUN8CHnE>... > Because Foundation do some optimize on your design, if it think a Signal or a port have no effection on the output, then the resourse about this part of design will be removed, so if you want to see a signal, you may use it as a output port! hey, thanks for the quick response. But thats not the problem. Even if i code is a simple D-FF i cant get the signal list in the ADD SIGNALS menu. kindly look into and suggest me something .Article: 37912
Ray, I agree completely with: "I am firmly of the opinion that folks need a solid digital hardware background before learning VHDL." What they're trying to do is turn a guy with a software education into a hardware designer by teaching him the syntax to VHDL. It doesn't work with ASICs, and it works even less well with the peculiar constraints of FPGAs. Carl -- Posted from firewall.terabeam.com [216.137.15.2] via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 37913
http://groups.yahoo.com/group/ASICDESIGN/?yguid=8794234 From: "hienpham2002" <hienpham2002@yahoo.com> Date: Mon Dec 24, 2001 9:52 am Subject: Re: Timing in FPGA --- In ASICDESIGN@y..., Suresh s <surr2k@y...> wrote: > hi, > > > I am using Spartan XL device for my design. > After Place and Route of my design I am not able > to meeet the timing in The Fpga. I want to know > how can I meet the timing in the device and available > options to meet the timing. > > > Suresh > Hello all, Basically, Suresh is asking how to speed up the circuit. What are the many ways to do so ? This could mean tweaking the codes (coding methodologies), or inserting certain commands into the synthesis program, P&R, or physically adding stuffs in the board. Ways to eliminate wait states are really up to your logic design. Ways to eliminating parasitic capacitance, routing delays, etc. might depends on synthesis optimization, and tweaking the PAR. Please comment on this. Thanks. Sanket, it's a good question and I hope you could enlighten us. Is there a FAQ or application note somewhere for this ? HienArticle: 37914
Rick Filipkiewicz wrote: > Ed Ngai wrote: > > But for many years all I ever dealt w/ was TTL, CMOS, ECL, GALs, some linear. > > And for maybe 16 years I 'never' touched upon a need for implementing FPGAs, > > using design tools, etc. Because of a jelly doughnut in 1994 I went into a > > Computer Literacy bookstore on Steven Creek and bought the FPGA Workbook by > > Dave Bout, Xess Engr. My 1st experience w/ an Intel FPGA, which Intel > > obsoleted. > I've finally found him - the other FX780/880 user! In fact Intel didn't obsolete > them they sold them to Altera. I believe Altera just wanted access to the Flash > technology and so they, Altera, obsoleted them 18 months or so later. By then, > of course, the XC95K devices were on stream ... I can't believe it, You Too?! Brings back the ole days of DOS 3.3 and PLD SHell. in fact ... scrounge around a bit, here it is.. PLDShell R1.0 Featuring PLDasm, reg card and everything. I made my 1st attempt of a state machine back then. > What used to impress me about these parts was not the silicon itself - though we have Intel > to thank for JTAG ISP - but how incredibly good the fitter was at making the best of the > device's meager resources. Used to take forever to run on an i486-66 but it got there in the > end, mostly.Article: 37916
I for one throw my hat in with schematics, but I no longer have access to anything worth using. I was once priviliged to use Compass VLSI schematic tools as part of VLSI's Asic flow, great edit in place tools written by VLSI guys for VLSI guys, produced beautifull ps output. Later schematic tools (for Windoze Veribest, Viewlogic etc) etc written by programmers who don't use their own tools (and don't have a xxxxxxx clue) had terrible implimentations, every thing got 100x harder (I am serious). You probably know how bad these tools can be. They could write netlists but wrote junk code (correct for simulation though). One chip database had 3Mbytes of Verilog netlist output, by time I rewrote it in Verilog myself it was 60K. No wonder we don't use those schematic tools, no wonder those guys have no business. Many digital systems have mixed signal content, who does analog in text? Nobody I am sure, you can't do analog with text. When doing analog, there is a right way to draw most of the std circuits to make it clear, diff pairs, mirrors etc. Grok in a sec iff you know the theory. When doing digital, well I still want to use schematics for top level block diagrams but when it comes to details, the schematic falls out of sync with simulation & text source. Every semiconductor company (Xilinx included) do use schematics in their marketing, we would not buy these parts if described with 0 drawings in a plain txt file. So why as users do we have to give up a tool that can make a picture worth a 1000 words. There is a way out of this mess though, the synthesis tools can synthesize schematics, but they are usually hopeless and also read only. I have begged Synplicity & that german company that writes these schema components to allow a drawing editor to adjust or annotate the synthed schematic. Initially if the schematic is synthed badly, just move the blocks into a position that makes more sense. Also treat similar vectored instances the same to allow good datapath (even if tool can't see it, I know where it is). Allow the symbols to be sized (proportionate to internal gate count), rotated, & enhanced by user to clarify. What is the point of having lots of tiny rectangles layed out strictly left to right. There are proper symbols for Muxes, ALUs, etc. Allow multiple renditions, symbols sized to reflect their hier content weight becomes a great floor planning tool. Even allow some changes to back annotate into original source (much harder). All this extra stuff the user adds, doesnt have to change the HDL source, it just becomes per schematic prefs so if the source is slightly changed, the schematic could be resynthed in a similar way to that just edited. I have even wondered if Visio or similar could be cajoled into an EDA tool, but that requires SDKs etc & netlisters etc etc. My 2 cents, it am sure it will never happen though till a user does it.Article: 37917
Milos Becvar wrote:
>
> Dear Kevin,
>
> we have recently solved simillar problem with our own PCI Core. You have to
> improve your design !
>
> Try to rearange your logic that input signals (IRDY, FRAME, DEVSEL, TRDY -
> from the
> most crucial paths) has the lowest number of logic levels.
>
Later in the message, you mention that for a Virtex -4 100k
system gate part to meet 33MHz PCI timings, the maximum level of LUTs
had to be 2 levels at the maximum.
When I first read your message, I thought that was impossible because I
already wrote the RTL, and didn't want to modify it, but I eventually
found of some bottlenecks in my design.
> In VHDL you should move these signals to outer IF's expresions (whatever
> duplication of inner conditional statements is introduced) to give it the
> highest priority.
My understanding of what you are saying here is that a data
transfer statement located on the outer side of the "if" statement have
less conditionals (inputs) going into LUTs than the ones on the inner
side of the "if" statement.
In one case, I modified my code to do transfer of data being supplied
from the user side bus to PCI bus even if the user side bus is inserting
wait cycles.
Previously, I checked the user side bus for data availability to
transfer data to PCI bus, but checking the use side bus requires an "if"
statement to do so.
When the user side bus is inserting wait cycles, TRDY# is being
deasserted, that shouldn't be a huge issue.
> Internal signals (from DFFs) have 30 ns to propagate through the comb.
> logic (they can pass more logic levels that IRDY, TRDY etc.).
I think what you are saying is that I should use register inputs
as much as I can.
Because of using registered inputs incurs one cycle of delay compared to
using raw signals off the PCI bus, I previously used that only for
address and command decode.
I rewrote my Verilog code to take advantage of registered inputs where
that one cycle of latency will not cause major problems like during a
Configuration cycle, a single cycle, or a beginning of a burst cycle.
I did see some improvement in reduction of design score after P&R, and
two logic levels reduction of level of logic for AD[31:0] tri-state
control (4 levels of LUTs to 2 levels of LUTs).
However, the level of LUTs for a signal path starting from FRAME# or
IRDY# to AD[31:0] remained at 4 levels.
> For example use IRDY to choose between the subexpression (where IRDY='1')
> and subexpression (where IRDY='0'). STOP has generally lower fanout than
> IRDY and FRAME, so it can be the second in the IF statements tree. Normally
> there is no difference for
> this to be synthesised as a mux or a LUT.
>
You sound like your PCI IP core implements an initiator feature,
but I haven't gotten that far yet (currently only supports target mode
only).
I can see that signals like DEVSEL#, TRDY#, and STOP# will be a signal
being fanouted in an initiator mode.
My guess is that, TRDY# will likely have a larger fanout then STOP#, and
STOP# will likely have a larger fanout then DEVSEL#, but that is still
my guess.
> All this can be done in HDL without vendor specific modifications.
> Check it visually after the synthesis step whether the logic is such as
> described.
>
Yes, I now see from a setup time report that getting rid of "if"
statements reduces the levels of LUTs.
This optimization should help me when I port my design to Altera FPGAs
like FLEX10KE or ACEX 1K.
> In our case (Virtex xcv100-4) 7 ns Tsu is achieveable only if
> there are two levels of logic for IRDY, FRAME and DEVSEL.
> We also applied about 6 hand placements, mostly for these critical
> paths, to move the comb.logic luts as close to the IOB DFF's as it is
> posible.
> (It is an iterative process and takes time until you find the best
> placement, in the -5 device
> this can be easily achievable).
>
> Good luck !
>
> Milos
The question I have is, why use Virtex speed grade -4?
Perhaps was the board manufactured before Virtex speed grade -5 became
avaiable?
Did you buy it from a company, or did you design you own?
Also, what kind of synthesis tool did you use for your PCI IP core?
If it doesn't have to be a secret, I will be interested to hear.
In my case, I used Insight Electronics Spartan-II Development Kit (US
$145) and free ISE WebPack 4.1.
The design was synthesized with XST.
Before you mentioned that you were able to get things done with
only 2 levels of LUTs, I was just accepting the fact that PCI's protocol
has some complexity, so having 4 levels of LUTs was inevitable.
Someone else who commented on my question mentioned that since PCI
signals get tri-stated at the end of a transfer, so it won't matter
transferring junk onto AD[31:0] unconditionally because PCI bus won't
see it.
I noticed in one state machine state of my code where data was being
transferred from the user side bus to the PCI bus during a target burst
read, I was checking for the end of a target burst transfer, target
abort request from the user side bus, and disconnect request from the
user side bus before transferring data from the user side bus to the PCI
bus.
I modified the code so that now it transfers user side bus data to the
PCI bus unconditionally regardless of the above mentioned conditions
occurring.
I resynthesized my PCI IP core, and this time I saw a huge drop in P&R
routing score! (still wasn't zero though)
I read the timing analyzer report, and saw that a signal path starting
from FRAME# or IRDY# to AD[31:0] went down from being 6 levels of logic
(4 levels of LUTs) to 5 levels of logic (3 levels of LUTs).
If I assume the maximum clock skew for setup time is correct (about 2.3
to 2.5 ns for Spartan-II 150K system gates speed grade -5 part), I am
now within a reach of meeting 7 ns Tsu if I used Floorplanner, but I am
not so sure if I should really trust the setup time number reported by
the timing analyzer report (I just posted a question titled: Should
clock skew be included for setup time analysis? This posting should
explain the concern I am raising here.) considering that a Spartan-II
speed grade -6 part can theoretically be sold as speed grade -5.
Anyhow, your suggestion really helped me reduce delays
significantly, and I will still try to reduce logic levels down to 4
levels (2 levels of LUTs)
Thanks,
Kevin Brace (don't respond to me directly, respond within the newsgroup)
Article: 37918Hi, I saw this year some basics of vhdl at school. I'm now looking for some kind of FPGA-starterkit who allows me to experiment on simple I/O like leds, LCD screens, com-ports, RAM, ETHERNET,etc that are accesible through a simple electronic board. I heard of a Xilinx starterkit but found it a bit expesive for the pour student I am :-( Thanks. David.Article: 37919
Phil Hays wrote:
>
> Kevin Brace wrote:
>
> > Hi, I will like to know if someone knows the strategies on how to reduce
> > routing (net) delays for Spartan-II.
>
> A few things.
>
> 1) Look very hard at how logic on failing paths is designed. Is there a simpler
> way to do the function? Can you split a complex function into two simple
> functions? Can you move some of the logic to the other side of registers?
>
I noticed I had a chain of "if" statements before a transfer to
AD[31:0].
That chain of "if" statements became a priority encoder, and that was
creating 4 levels of LUTs (6 levels of logic if an input pin and an IOB
FF is included).
I got rid of the "if" statements, and the levels of LUTs dropped from 4
to 3 which improved timings significantly.
> 2) Does XST re-order logic? If so, you might make sure that the order of
> functions is good:
>
> x= f(a,b,c,(f(d,e,f,g)) will be faster for a,b and c than for d,e,f and g. Fine
> if a is the critical signal, bad if g is.
> Change it to (and I don't know enough about XST to tell you how to do this):
>
> x= f(g,a,b,(f(c,d,e,f)) or similar with the speed critical net having the fewest
> levels of logic.
>
> [f(a,b,c) is a three input lookup table with input signal a, b and c]
>
I am not sure if XST reorders logic because I haven't found any
synthesis option like that.
Perhaps, FF retiming might be the closest thing you are talking about,
but that feature doesn't work for IOB FFs.
> 3) What effort level are you running PAR at? "5" is the highest. Use it.
>
Yes, I am already using that option with an Extra Effort option
(I always do so because it give the best timings.).
> > Here are some solutions I came up with.
> >
> > 1) Reduce the signal fanout (Currently at 35 globally, but FRAME# and
> > IRDY#'s fanout are 200. What number should I reduce the global fanout
> > to?).
>
> If you have a problem with fanout, you may want to control how the fanout is
> split up. Telling the synthesis tool to reduce fanout isn't good, as the
> synthesis tool does not have a clue as to how the logic is located, so it may
> split the net in a way that makes no sense. No, I should say it will split nets
> in ways that make no sense. This may mean that you will need to add a module to
> your design with the buffering for this net. Again, I don't know how to force
> mapping of logic in XST.
>
>
XST does have some features that let the user control fanout,
but the most I have done is specifying fanout for individual inputs.
I suppose that there might be a way to force a particular LUT to have
fanouts below certain number, which I haven't tried it yet.
> > 3) Floorplan all the LUTs and FFs on the FPGA (currently, I only
> > floorplanned the LUTs that violated Tsu, and most of them take inputs
> > from FRAME# and IRDY#.).
>
> Logic that is near the critical paths may need to be floorplanned to avoid
> interaction with the critical path. "Near" can be logical or physical.
>
I started to pay more attention on what is connected to a LUT
even if some inputs don't seem important.
I suppose FPGA Editor might let the user see the values stored inside a
4-input LUT, but ISE WebPack only comes with Floorplanner, and
Floorplanner doesn't let me see that (I understand that a 4-input LUT
has 16 different results already stored inside).
If I can see the LUT values inside, I think I can have a better
understanding of what a LUT is doing.
> > 4) Use Guide file Leverage mode in Map and Par.
>
> This might help. To use this feature, make a sub-design with the critical path
> and as little else as reasonable, and PAR this design into "my_guidefile.ncd".
> Then go a guided MAP and PAR with this as a guide file.
>
Hopefully, Xilinx will fix the Leverage Mode bug in PAR in the
next release of ISE WebPack.
> > P.S. Considering that I am struggling to meet 33MHz PCI timings with
> > Spartan-II speed grade -5, how come Xilinx meet 66MHz PCI timings on
> > Virtex/Spartan-II speed grade -6? (I can only barely meet 33MHz PCI
> > timings with Spartan-II speed grade -6 using floorplanner.)
>
> They are good, and they cheat. Their design is clever and well done, and they
> use a "magic_box" , a bit of dedicated logic that can only be used from
> FPGA_editor.
>
ISE WebPack doesn't come with FPGA Editor . . . (I wish it did)
However, I still want to keep my PCI IP core vendor independent, I don't
plan on using it, but it is always good to know how that thing works.
One interesting thing one person told me is that Xilinx uses
Address/Data Stepping in their PCI IP core.
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10397
I cannot think of many PCI devices using this feature because the use
incurs performance penalty, but that might be negligible in a long
initiator burst transfer.
Use of this feature is, of course, allowed by the specification, but I
don't think in general devices are encouraged to use it.
Some people might disagree with me, but I think use of Address/Data
Stepping can be considered cheating because it shows that the Xilinx had
to use this feature that is known to lower performance perhaps to meet
66MHz PCI timings.
> > I know that Xilinx uses the special IRDY and TRDY pin in LogiCORE PCI,
> > but that won't seem to help FRAME#, since FRAME# has to be sampled
> > unregistered to determine an end of burst transfer.
>
> Question to make you think: What do you NEED to do at the end of a burst
> transfer? And when?
>
> --
> Phil Hays
I can think of turning off signal drivers (i.e., tri-stating
AD[31:0]).
Thanks,
Kevin Brace (don't respond to me directly, respond within the newsgroup)
Article: 37921
Carl Brannen wrote:
>
> Kevin, I was under the impression that Xilinx put the IRDY and TRDY hardware
> in there because without it they couldn't guarantee PCI compatibility.
>
> > Regarding the "built-in PCI logic," I will assume what you mean
> > is Xilinx's special IRDY and TRDY logic.
> > Because the PCI IP core has to be portable across different platforms, I
> > am not interested in using that special IRDY and TRDY logic, and I don't
> > really know how it works.
>
> I had a design once where the customer selected the pins himself, and I had to
> make them cut and jumper the prototypes in order to get the PCI IP installed
> right.
>
I can imagine that must have been a nightmare.
In my case, the pins the Insight Electronics Spartan-II PCI development
board uses for IRDY# and TRDY# (pin 24 for IRDY# and pin 27 for TRDY#)
uses the correct pin where the special IRDY and TRDY logic is located.
> The Xilinx PCI logic takes an IRDY and a TRDY input, along with I1, I2, and I3,
> and produces an output called "PCI_CE". It's intended use is as a clock
> enable for when the xilinx drives the CBE[3:0] and AD[31:0] outputs. That
> should give a clue about what the logic in it is. This should give another
> clue:
>
> http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10397
>
> Since IRDY and TRDY are being brought in as inputs, I suppose this logic
> applies to the case when the Xilinx is a bus master, and it's used to extend
> cycles when the slave isn't ready. The idea would be to keep CBE constant
> (and AD too, if it was a master write cycle), if the slave responded with
> a not ready response. But it's been a while since I looked at a PCI spec.
>
Very interesting link.
I don't visit their support page often, so this is the first time I saw
this page.
Address/Data Stepping is a feature known to lower PCI bus performance,
and I don't know many devices that actually uses it.
I am sure that someone from Xilinx will disagree, but the use of
Address/Data Stepping seems to show that Xilinx "barely" met the PCI
timings (maybe not 33MHz PCI, but the much harder 66MHz PCI) with the
use Address/Data Stepping and the special IRDY and TRDY logic.
They certainly didn't violate the PCI specification, but I will
personally call the use of these features "cheating."
Of course, if an initiator does a long burst transfer, the performance
penalty of the use of Address/Data Stepping might be negligible.
> I'm pretty sure that if it were possible to make a Xilinx PCI IP core without
> the special logic, Xilinx would have done it. On the other hand, maybe their
> new parts are enough faster than before that the special logic isn't needed.
>
Yes, the PCI IP core I am working on has a requirement of not
using any vendor specific features at HDL level.
All I care is to meet 33MHz PCI timings, and not bother with 66MHz PCI.
I am sure that Xilinx would have preferred not implementing any special
features into their silicon just for one application (PCI).
I heard that Xilinx got rid of that special IRDY and TRDY logic in
Virtex-II.
> One thing I like about Xilinx is that their silicon has always been pretty much
> rock solid for me. I've never had a real complaint about their silicon, but
> I complain all the time about their software. If something acts silly it's
> always because I've got signal integrity issues (or whatever), but they're not
> Xilinx' fault.
>
> Carl
>
How about Altera's silicon and software?
I don't really have a favorable opinion of Altera's free synthesis tool
(Mentor Graphics' (Exempler Logic) LeonardoSpectrum-Altera. Although
Altera didn't write the software, so it is not directly Altera's
fault.), and I am not a fan of MAX+PLUS II.
I haven't played around with Quartus II 1.1 Web Edition that much, so I
don't know what it will be like.
> I always try to register all my inputs and outputs in the IOBs because that
> makes it a lot easier to analyze timing for the system. It breaks the system
> timing calculations into two parts. (1) Getting on and off of the Xilinx, but
> all those signals have pretty much the same timing, and (2) moving data around
> inside the Xilinx, but the tools handle that for me. I guess you can't
> simplify to that kind of system with a PCI interface.
>
> --
> Posted from firewall.terabeam.com [216.137.15.2]
> via Mailgate.ORG Server - http://www.Mailgate.ORG
I noticed there are some situations in PCI where registered
inputs can be used, but from my experience, the part that causes timing
problems is when "raw" (non-registered) data has to be used from PCI bus
directly.
For example, when the PCI IP core is handling a no wait target burst
read cycle.
Potentially (I haven't worked on an initiator version of PCI IP core
yet), during an address phase of an initiator and during a no wait
initiator burst write cycle.
Thanks,
Kevin Brace (don't respond to me directly, respond within the newsgroup)
Article: 37922
Austin Franklin wrote:
>
> Hi Carl,
>
> > I'm pretty sure that if it were possible to make a Xilinx PCI IP core
> without
> > the special logic, Xilinx would have done it. On the other hand, maybe
> their
> > new parts are enough faster than before that the special logic isn't
> needed.
>
> It IS possible to make a PCI "core" that does not NEED the special logic,
> and have it be fully compliant at 33MHz, it does though ease the timing.
>
One thing I am wondering is whether or not I can claim "my
design met 7ns setup time" based on the timing report Xilinx Timing
Analyzer generated.
When TRCE or Xilinx Timing Analyzer does setup time analysis, it
subtracts clock skew from data path delay (data path delay = gate delay
+ routing delay), but this clock skew can be substantially lower at room
temperature, and from the impression I get, the clock skew number is the
worst case clock skew number (good for Tsu, bad for Tco(Tval)), and not
the best case number (bad for Tsu, good for Tco).
I do realize that LUT, FF, and routing delay will be lower at room
temperature.
Perhaps, should I get data path delay below 7ns before I can claim "my
design met 7ns setup time?"
That seems to be pretty hard especially for larger density devices of a
given device family because routing delay gets larger as the die gets
larger.
> Also, to answer some of what Kevin wrote...you DO need to use some of the
> raw PCI signals (as well as the same signals registered), I don't remember
> which ones off the top of my head, but I can take a look at one of my PCI
> cores if you are interested.
>
> Regards,
>
> Austin
Yes, I will be interested to know when you used the registered
ones and when you had to use the raw signals.
I modified my code to use register signals when multiple wait cycles
were being inserted like during a single transfer (Configuration,
memory, and I/O) or a first transfer of a burst transfer.
However, during a no wait target burst cycle, I had to use raw signals.
Use of registered inputs helped somewhat in my case (reduced LUT levels
for some paths), but I eventually figured out that during a target burst
read cycle, I had a chained "if" statements (synthesis tool will
synthesize a priority encoder), and that was creating more LUT levels.
I got rid of the "if" statements, and I got LUTs levels from 4 levels to
3 levels (some of them to 2 levels of LUT), which improved timings
significantly.
I think I can say that HDL is nice, but if the designer is not being
careful, the synthesis tool might create circuit that runs slow.
In search of some clues that will improve timing, I found
several of your postings to news:comp.arch.fpga about PCI between 1997
to 1998 (Google's search engine is pretty good in finding past
articles).
You mentioned that you used schematics for your PCI IP core, but what
was the worst level of LUTs your design had for a signal path starting
from FRAME# and IRDY# to one of AD[31:0] after P&R?
Also, you mentioned in one of the past postings that Xilinx was
initially interested in buying or licensing your PCI IP core, but turned
it down in favor of another vendor.
I forgot the name, I thought it was something like High Speed Design or
High Performance Design, but what happened to that company?
Did Xilinx acquire that company, considering that Xilinx and Altera were
actively buying IP design houses back in the late '90s when their market
cap. were doubling almost every year?
I don't know how things were going in Xilinx back then, but why couldn't
Xilinx develop their own PCI IP core internally without buying from
outside?
Thanks,
Kevin Brace (don't respond to me directly, respond within the newsgroup)
Article: 37923
Eric Crabill wrote:
> Hi,
>
> > What kind of tricks is Xilinx using in their
> > LogiCORE PCI other than the special IRDY and
> > TRDY pin? Does anyone know?
>
> No tricks are employed. I would prefer to think
> we use careful and deliberate logic design. The
> special logic resource to which you refer is only
> required for 66 MHz designs in devices pre-dating
> Virtex-II.
>
> There you go,
> Eric
I guess "careful and deliberate logic design" you mean is
something like reducing input terms going into LUTs, and do unnecessary
or unconditional (in HDL, not puting an "if" statement to do a transfer)
transfers to FFs when there are no side effects of doing so.
Thanks,
Kevin Brace (don't respond to me directly, respond within the newsgroup)
Article: 37924I am wondering if there is kind of software which I can easily draw and edit bus signal waveforms with a mouse and a keyboard, and print it out from a printer. I can think of Altera MAX+PLUS II-BASELINE's waveform editor, but does anyone else know something better? I will like to improve my productivity, and one thing that took forever during a design I worked on was drawing sample waveforms of a design I am working on sheets of paper with a pencil and a ruler. From these sample waveforms I think about how I will design state machines and when I should change a value of a FF. After the state machine design is done, I go into HDL coding. So, does anyone know such a tool I am talking about? Thanks, Kevin Brace (don't respond to me directly, respond within the newsgroup)
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