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
Hi all, I have just installed Xilinx ISE5.1 SP3 and the Synthesis tool always aborts the Compilation at the End giving the following Error: ---------------------------------------------------------------------------- ------------------ FATAL_ERROR:Xst:Portability/export/Port_Main.h:126:1.13 - This application has discovered an exceptional condition from which it cannot recover. Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.com Error: XST failed Reason: Completed process "Synthesize". ---------------------------------------------------------------------------- ------------------ The main memory of my PC is 512MByte and should not be the problem I did not find any helpful Xilinx Info yet. Does anyone have any idea? thanks peterArticle: 51951
Hi, How specify with XST synthetiser (Xilinx) to encode FSM in "safest way", that is to say, to include the "when others" choice (when I write "state <= State_Init;"), put in case of clock problem or something else (in order to be sure to be in a know state) ? This is particulary useful when we use one hot encoding where binary values of state register with many '1' are not normally taking account. I previously use FpgaExpress and it had this option... Thanks in advance.Article: 51952
How are you using the RAM? If it is a always accessed sequentially, you can
make a 'sidecar' out of SRL16's If not, then you'd have to use CLB RAM,
which means addition resources for addressing and muliplexing. Performance
will probably suffer more than you'd like for a random access 2K deep memory
in CLBs.
RISC taker wrote:
> Hi,
>
> thanks for the tips!
>
> "John_H": <johnhandwork@mail.com> wrote:
> > So you're willing to toss 50% of the depth and add several
> > CLBs rather than toss 44% of the width with no additional resources?
>
> No! Sorry, I might have explained this wrong. I don't want to waste
> ANY % of the block RAM. In fact I am dividing the block into two
> separate RAMs. One port accesses the first half of the depth, the
> other port independently works on the second half. Now I thought about
> extending the structure with LUTs by one bit. Single port distributed
> RAM will do (half-depth twice), as the ports don't address any shared
> memory, but only their own half.
>
> I will try to see if and how it works.
>
> > Are you seriously using all (most?) of your available BlockRAM elements?
> > I'm used to designs with BlockRAMs that sit idle.
>
> I'm making a design with several parallel processing elements (PEs).
> Each PE uses 2 multipliers and 2 block RAMs (so far). They use up more
> RAM than logic. I consider a XC2V250, so I could fit 10 PEs into it
> (20 RAMs). The remaining 4 RAMs are needed for a central unit that
> schedules the work to the PEs.
>
> If I throw in a 3rd block RAM, I can only fit 6 PEs (instead of 10).
>
> There is still a lot to develop. Right now I have unused LUTs. If I
> see later that I need much more logic, I still have this option.
>
> Thank you!
> Dennis
--
--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: 51953itsme <itsme@gmx.de> wrote: : Hi all, : I have just installed Xilinx ISE5.1 SP3 and : the Synthesis tool always aborts the : Compilation at the End giving the following Error: : ---------------------------------------------------------------------------- : ------------------ : FATAL_ERROR:Xst:Portability/export/Port_Main.h:126:1.13 - This application : has discovered an exceptional condition from which it cannot recover. : Process will terminate. To resolve this error, please consult the Answers : Database and other online resources at http://support.xilinx.com. If you : need further assistance, please open a Webcase by clicking on the "WebCase" : link at http://support.xilinx.com : Error: XST failed : Reason: : Completed process "Synthesize". : ---------------------------------------------------------------------------- : ------------------ : The main memory of my PC is 512MByte and should not be the problem : I did not find any helpful Xilinx Info yet. Did you look in all the .log file that were produced? Mostly there is some helpfull information. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 51954
Hello. I have looked at the Virtex 2 handbook and I still can't find
the answers I need. Maybe I'm not reading right.
The problem is that I want to know the relationship between the 8
differential clocks (from the 16 pads) and their availability. Are
they by quadrants or are they global?? If they are by quadrants, which
quadrant are they available in? It looks like the differential clocks
from BUFGDS are global but it's not really clear.
Another question is that I don't know how to pair them off.
For example which is the differential pair of GCLK1P. Is it GCLK1S or
GCLK0S(based on the IO differential pair)?
Thanks a lot,
- Paulo Valentim
Article: 51955Hello, Using Virtex If we implement an N-bit adder using the carry logic will not the 2N-bit adder run at half the speed of N-bit adder This what i expect, but i have read that this not the cases with carry logic of Virtex,i.e. its propagation delay is not linear? is that true? if yes, how is the propagation delay of the carry Logic thanksArticle: 51956
You have several elements that make up the maximum speed of your adder. The delay elements that will roughly double are the carry delays between slices. Everything else, however, remains pretty well fixed. The clock to out from the registers that hold the addends add to the routing delay from those registers to the carry chains where there's a specific time to get into the chain elements. Once past the (doubled) very fast carry "bypass" delays, another time is encountered to get off the carry chain and into the register. If the result isn't registered within the carry chain, it's a diffferent time to get off the carry chain, more routing, and the clock to in time for the next register. There's so much more to maximum speed than the time it takes to push up the carry chain. The interactive data sheets for things like the Spartan-IIE or Virtex-II parts are helpful for visualizing how the delays are routed through the slices or IOB cells. It's a good resource. "Moss Ben" <mosaab2k@yahoo.com> wrote in message news:7014b7dd.0301270758.dc5716d@posting.google.com... > Hello, > Using Virtex > If we implement an N-bit adder using the carry logic > will not the 2N-bit adder run at half the speed of N-bit adder > This what i expect, but i have read that this not the cases with carry > logic of Virtex,i.e. its propagation delay is not linear? > is that true? > if yes, how is the propagation delay of the carry Logic > thanksArticle: 51957
Glen, that problem was fixed many years ago. We old users have this need to get rid of the cobwebs occasionally. I know the problem... Peter Alfke glen herrmannsfeldt wrote: > "Ray Andraka" <ray@andraka.com> wrote in message > news:3E32F64E.73A27950@andraka.com... > > That is more or less correct. A LUT and a ROM are physically the > same thing > > really, just that the LUT sort of implies a logic look up where a > ROM sort of > > implies data. The RAM is unique in that its contents are > intended to be > > rewritten. > > Last I knew (XC4000 days) it was not possible to initialize a LUT > based RAM. The hardware couldn't guarantee against glitches on the > R/W line at the end of initialization. So, in FPGA sense, LUT are > ROM and not RAM. > > -- glenArticle: 51959
Houman, Your project (hopefully successful) is good for humanity, so you should get all the support you need. If I were you, I would develop a concept, then guess the size ( number of flip-flops and RAM bits) and then look at Spartan-II or Virtex-II devices, unless you need an on-chip microprocessor, in which case look at Virtex-IIPro. Let me know once you have a clearer idea. I know it may not be significant business (hell, we will donate the FPGA !), but it might give me a good feeling of perhaps contributing to saving some kid's legs or life... Peter Alfke, Xilinx Applications ======================================== Houman wrote: > Hello everyone... > I'm working on a university design project and i'll be using FPGA. I'm new > to this and don't really know where is a good place to get started. > > Our design project is a mine-detecting robot. The robot will cover a > rectangular grid, scanning for metals (using an inductive coil sensitive to > different metals). > The FPGA will take inputs from the coil and other sensors (for position of > the coil and the robot in the grid). > The FPGA also controls the servo motors using PWM. > Once a metal (mine) is detcted, the FPGA will relay the information > regarding the coordinate of the mine to a PDA. > > Any feedback/help will be greatly appriciated. > > thank you all in advance > cheers, > HoumanArticle: 51960
The time to get on and off the ends of the carry chain are much greater
than the incremental carry chain, so you may not recognize the deltas due
to just the carry chain. Also, the carry chain is implemented with a fast
carry lookahead at the slice level, so the speed of 1 bit vs 2 bits is
virtually the same.
Moss Ben wrote:
> Hello,
> Using Virtex
> If we implement an N-bit adder using the carry logic
> will not the 2N-bit adder run at half the speed of N-bit adder
> This what i expect, but i have read that this not the cases with carry
> logic of Virtex,i.e. its propagation delay is not linear?
> is that true?
> if yes, how is the propagation delay of the carry Logic
> thanks
--
--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: 51961
glen herrmannsfeldt wrote:
> "Ray Andraka" <ray@andraka.com> wrote in message
> news:3E32F64E.73A27950@andraka.com...
> > ... A LUT and a ROM are physically the
> same thing.
For Virtex and later, the problem with initializing RAM is no longer
there.
>
>
> Last I knew (XC4000 days) it was not possible to initialize a LUT
> based RAM. The hardware couldn't guarantee against glitches on the
> R/W line at the end of initialization. So, in FPGA sense, LUT are
> ROM and not RAM.
>
> -- glen
--
--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: 51962
Alain wrote:
> How specify with XST synthetiser (Xilinx) to encode FSM in "safest
> way", . . .
> I previously use FpgaExpress and it had this option...
If XST has no "safe" setting for one-hot, consider using
binary encoding as it is inherently safe.
-- Mike Treseler
Article: 51963The tragedy is that I used to write this stuff ALL the time, and far more complex stuff too. I even wrote my own version of TECO (in FORTRAN) so that I could continue to use it while programming on PR1ME computers. Now I look at the example below, and I finally see that it is not obvious what it does, and that it does look (a little) like modem line noise :-) (or a little like Perl). Philip Freidin On 27 Jan 2003 08:44:55 +0000, Martin Thompson wrote: >For those who really want to know, excerpt from the Jargon File enry >for TECO (http://catb.org/~esr/jargon/html/entry/TECO.html) > >---- begin quote ---- > >As an example of TECO's obscurity, here is a TECO program that takes a >list of names such as: > >Loser, J. Random >Quux, The Great >Dick, Moby > >sorts them alphabetically according to surname, and then puts the >surname last, removing the comma, to produce the following: > >Moby Dick >J. Random Loser >The Great Quux > >The program is > >[1 J^P$L$$ >J <.-Z; .,(S,$ -D .)FX1 @F^B $K :L I $ G1 L>$$ > >---- end quote ---- > >Cheers, >Martin Philip Freidin FliptronicsArticle: 51964
Philip Freidin wrote...
> The tragedy is that I used to write this stuff ALL the time,
> and far more complex stuff too. I even wrote my own version
> of TECO (in FORTRAN) so that I could continue to use it while
> programming on PR1ME computers.
That's what I call dedication.
> Now I look at the example
> below, and I finally see that it is not obvious what it does,
> and that it does look (a little) like modem line noise :-)
> >[1 J^P$L$$
> >J <.-Z; .,(S,$ -D .)FX1 @F^B $K :L I $ G1 L>$$
> (or a little like Perl).
Thanks to my colleague Simon Dempsey for a
re-implementation in Perl...
for(sort<>){/(.+?), (.+)/;print"$2 $1\n"}
Great to see how far we've moved on in terms of
lucidity and elegance since those dark days :-)
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 51965Robert Koch wrote: > Hi! > > Is it possible to convert the old schematics sources (made with XILINX > XactStep 1.5i) into any format which can read Mentor HDL-Designer > (graphics and/or VHDL)? > > I thank you all for your tipps! > > Robert > > I never do it. But try: 1.From Xact 1.5i generate the vhdl ouput files as you generate it for a post P&R simulation. 2. From HDS, import the vhd files. 3. As the vhdl files will be based on Xilinx components, you will need to import the Xilinx Lib too. Let me know Laurent www.amontec.comArticle: 51967
Riccardo Rubini <riccardo.rubinixxx@yyytin.it> wrote: Hi Riccardo, > I am looking for a used PAL programmer able to handle 16L8 / 20L8 PALs. Have a look at http://www.geocities.com/mwinterhoff/program.htm Best regards, Christoph > RiccardoArticle: 51968
Hello, i'm designing a board with a VirtexII that takes masses of data from several inputs and stores it in 2 DDR-RAM channels. For the ram-controller i'm orientating on xapp200. It says to feed the ddr_clk and possibly ddr_clkb back into the fpga. My question is how to route this feedback on the pcb? I see several possibilities: - shortest way from pad to pad - from the series termination resitor - from the ram-socket - from the parallel termination resitor And how do i terminate this feedback? (DCI is not an option) Any help welcome Thank You in advance FlorianArticle: 51969
"Houman" <abrishamkar@ieee.org> wrote in message news:<b11ino$cck2@mercury.cc.uottawa.ca>... > Hello everyone... > I'm working on a university design project and i'll be using FPGA. I'm new > to this and don't really know where is a good place to get started. > > Our design project is a mine-detecting robot. The robot will cover a > rectangular grid, scanning for metals (using an inductive coil sensitive to > different metals). > The FPGA will take inputs from the coil and other sensors (for position of > the coil and the robot in the grid). > The FPGA also controls the servo motors using PWM. > Once a metal (mine) is detcted, the FPGA will relay the information > regarding the coordinate of the mine to a PDA. > > Any feedback/help will be greatly appriciated. > > thank you all in advance > cheers, > Houman Is this for academic credit or an effort to really tackle the problem, different answer, very different solution. I am thinking that for quite a few wars where mines were used in vast nos, that most robots are not going to be effective, thinking soft terrain, thick vegetation, rice paddy fields etc. The evil thing is that many of these mines were designed not to be sensed as well, not being a big lump of metal. Also be aware that the new smart mines are designed to gang up on each other, only going off if they collectively thinks thats lots of troops are in reach of several devices. Sic. Hopefully you could get help from the companies that made the darn things, or atleast some information about detecting them. Why not try contacting the organisations that Princess Diana was so involved in for help. Google Princess Diana land mines gives 5000 refs. Even for places where surfaces can be crawled, driven etc, thats a lot of terrain for such a small robo. If its a big robo, then costs will be very high. Off the top of my head how about getting higher and covering a larger field by raster scanning the ground in the biggest swathes possible. I can feel that the sensor can't get that high though, but the higher you can get, the more ground can be covered quickly. That way a more complex robot problem gets turned into a DSP sensing problem, then a human/vehicle can then move the device forward if it sweeps a good area. Good luckArticle: 51970
But the path from the LSB to the MSB should also be taken into consideration. The change in delay of this path when increasing the size of the adder will depend mainly on the route delay from a slice to a slice. if i have understood you well, you mean that such delay is negligeable in from of the time in,time-out of the registers. is that right? John-H you speak about interactive data sheets, could u please post the URL. v just checked Xilinx, there is only PDF file. thanks Ray Andraka <ray@andraka.com> wrote in message news:<3E35754B.BB2C81F3@andraka.com>... > The time to get on and off the ends of the carry chain are much greater > than the incremental carry chain, so you may not recognize the deltas due > to just the carry chain. Also, the carry chain is implemented with a fast > carry lookahead at the slice level, so the speed of 1 bit vs 2 bits is > virtually the same. > > Moss Ben wrote: > > > Hello, > > Using Virtex > > If we implement an N-bit adder using the carry logic > > will not the 2N-bit adder run at half the speed of N-bit adder > > This what i expect, but i have read that this not the cases with carry > > logic of Virtex,i.e. its propagation delay is not linear? > > is that true? > > if yes, how is the propagation delay of the carry Logic > > thanks > > -- > --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, 1759Article: 51971
Hi, I am using excalibur Device. In my design I want to route one fast(12 MHz) clock from one port of one component to another port of another component. Since the clock is fast I want to route it through global clock tree. How can I do that? Is that I have to take the clock to an external pin and then route or else any other way is there?Article: 51972
For Virtex, the delay for a bit increment on the carry chain is small. If all else is
perfectly constant, you'll see a linear increase in delay (in at LSB to MSB out) for every
2 bits added, but keep in mind that incremental increase in delay is very small compared
to the delays for routing to/from your adder. A small change in the routing, (which will
happen with the automatic router in software versions 4.1 and later, even if all the
placement is locked down) will easily swamp the small increase in the delay due to adding
more bits. If you want to truely measure it, you will probably have to hand route the
adder using FPGA editor. You can get sort of close by floorplanning and specifying the
design so that there are registers immediately before and after the carry arithmetic, and
physically place the outputs in the same slice, the inputs register in an adjacent slice.
For routers in the software versions preceding 4.1, that would be sufficient to get an
optimal route. With the newer software, you will often get rogue paths that run longer
than the optimal path, but that meet the time constraints given (and there isn't an easy
way around it with arithmetic because the upper bits have slack if the timing is slack
enough to handle the lsb to msb case).
Moss Ben wrote:
> But the path from the LSB to the MSB should also be taken into
> consideration. The change in delay of this path when increasing the
> size of the adder will depend mainly on the route delay from a slice
> to a slice. if i have understood you well, you mean that such delay
> is negligeable in from of the time in,time-out of the registers. is
> that right?
>
> John-H you speak about interactive data sheets, could u please post
> the URL.
> v just checked Xilinx, there is only PDF file.
>
> thanks
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3E35754B.BB2C81F3@andraka.com>...
> > The time to get on and off the ends of the carry chain are much greater
> > than the incremental carry chain, so you may not recognize the deltas due
> > to just the carry chain. Also, the carry chain is implemented with a fast
> > carry lookahead at the slice level, so the speed of 1 bit vs 2 bits is
> > virtually the same.
> >
> > Moss Ben wrote:
> >
> > > Hello,
> > > Using Virtex
> > > If we implement an N-bit adder using the carry logic
> > > will not the 2N-bit adder run at half the speed of N-bit adder
> > > This what i expect, but i have read that this not the cases with carry
> > > logic of Virtex,i.e. its propagation delay is not linear?
> > > is that true?
> > > if yes, how is the propagation delay of the carry Logic
> > > thanks
> >
> > --
> > --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: 51973
Rob Finch wrote:
> I prefer Verilog, I think it partly has to do with linguistics. The issue I
> have is not with the number of characters typed, I find it much easier to
> read than VHDL. For instance, which is harder to read "downto" or ":" ?
> Generally I find fewer characters easier to read to a point. What is a
> "std_logic_vector" ? The concatonation of three different components
> confuses me. It really is just one idea, so why represent it with three
> different meaning components ? If it's a standard, then why do I have to
> type in 20 characters ? Why can't I just type "vec" ?
A few points.
1) if you want to just type "vec", you can create a type 'vec' and use that till
the cows come home.
2) When dealing with arithmetic intensive designs, the strong typing can be a
blessing, especially when mixing signed and unsigned types. A std_logic_vector
is just a collection of bits, and as such arithmetic is inherently undefined
until you specify what the arithmetic system is. Verilog presumes, and will
often get you into trouble in this regard.
>
>
> Having a lot of different strictly defined types is not necessarily a good
> thing. It all depends upon what the goal is. Without strictly defined types,
> I find it easier to generalize my understanding of code.
>
> If there is something that is complex to understand in the code, then I use
> the following method: I document it with comments.
>
> Something I don't understand about VHDL: why would one use different RTL and
> behavioural code ? If you're testing something, wouldn't you want the code
> being tested to be the same as the code synthesized ?
To speed up simulation: substitute behavioral models for parts of the circuit
you are not testing but need to be present to work with the part under test. A
gate level model of a big design takes an awful long time to run. A good
behavioral model can reduce the sim time by orders of magnitude.
To be able to simulate a design before the detailed design is completed. Again,
somehting that can be used to keep a big project moving along and on schedule.
>
>
> VHDL peeves:
> elsif / when / others and others things
> quotes around numbers
> round brackets for indexing
> etc.
>
> Rob
--
--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: 51974The 9050 has lots of features - can you give more details on your requirements. Mike D - (vetern of many PCI battles) "praveen" <praveenkumar1979@rediffmail.com> wrote in message news:ff8a3afb.0301270320.7d7ac22e@posting.google.com... > hello sirs/friends > i am writing vhdl code for PCI bridge to be specific i am trying to > implement PLX 9050 bridge. I have understood the protocol. But i donot > know the internal design details of that chip. i am total lost. > please help me . if you have done any project of this kind please send > the design details of it. u can mail it my email id. how to > start????.module level?????how??? > > waiting for ur reply > thanks in advance > praveen
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