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
Rick Collins wrote: > > We are working on a design in an XC4000 about 64K gates and are having a > problem with register replication. The P$R tool is replicating a FF that > is the critical element of a cross clock domain synchronizer. I call > this a "bad thing". > > We looked at the Xilinx web site and found Answer #3813. This says that > PAR can split a net and duplicate the FF driving it. Of course this will > break a synchronizer, they even mention this. The solution is to use an > environment variable to control this feature. This seems like a very odd > way to control the PAR tool! Is there no option that can be set for > this??? Has anyone else been bitten by this "issue"? Any other > solutions? > > I don't really understand why PAR wants to split this net. The > synchronizer consists of two FFs on the same clock with an AND gate > detecting the two FFs being of different values to generate a single > clock wide pulse. The first FF output feeds only three inputs, yet this > is the net that was split. Anyone understand why this is happening? I've been bit by this, with a fanout of two(!). I did the following: 1) Set the magic word (environment variable). This alone would probably solve the problem. 2) Forced the PAR tool to do the correct thing even if the magic word didn't work: LOCed the FF to a CLB LOCed an unrelated FF to the same CLB (repeat for all similar synchronizer FFs) (I could have RLOCed rather than LOCed for somewhat more reusable code.) The FF will only be duplicated if the other FF in the CLB is unused. This alone would probably solve the problem. 3) Added one more stage to the synchronizer. With a fanout of 1 the added FF will not be duplicated. This alone would probably solve the problem. 4) Verified that these FF were correctly built manually each time before releasing a bit file. Yea, this was more than a bit paranoid, but just because I'm paranoid doesn't mean that something isn't out to get me. The reason why this happens is that some programmer in X-land added an optimization to PAR for XC4000's that will add a duplicate FF if any time or routing resource can be saved. This is good, if your design has a single clock. This is very evil if you have multiple clocks. -- Phil HaysArticle: 34176
http://www.asciimation.co.nzArticle: 34177
On 15 Aug 2001 14:10:31 -0700, fr_a69@hotmail.com (Frederic Antonin) wrote: >I discover a major performance problem with Modelsim > >When your simulating a design using a ram the memory array is usually >describe that way in verilog: > >reg [mem_with - 1 :0] my_memory [0: mem_deep - 1]; > >If your memory deep is more than a couple to hundred (mine is 521k for >example) >you can't even display a single memory location (16 bit) without >having all your system ressources used and all you ram used (i have >1Gb or ram and it use all) > >If you'r lucky and patient and you PC doesn't crash when you drag your >memory location from the signal window to the wave window don't think >your done. >Running a simulation is just impossible the sumulator just rumm >forever to do nothing. > >I think the worste about it is that I contact them to report the >problem but they don't seems to care about it. > >If any of you know a "smart" simulator that is able to handle that >kind of case let me know. Fred, You could try to work within the limitations of your simulator, and modify your model of the ram to save its contents to a file when given a command (e.g. an edge on a signal). You can then look at the saved file using your favourite editor. That's how I do it, anyway. Allan.Article: 34178
>We are working on a design in an XC4000 about 64K gates and are having a >problem with register replication. The P$R tool is replicating a FF that >is the critical element of a cross clock domain synchronizer. I call >this a "bad thing". Did you spot this by eyeball? Or did you encounter a problem and track it back? The normal synchronizer setup is a FF, a short wire, then another FF, with both FFs running on the same clock. So I assume it replicated the second FF. I don't see any problem with that as long as both wires from the first FF are short. I would get uncomfortable if it put the second FF on the opposite of the chip. (I'd be uncomfortable with that even if it didn't replicate the FF.) The idea is that the first FF may go metastable. If so, you have most of a clock cycle for it to stabalize. You have to subtract the setup time, the clock to output time, and the routing time from the cycle time to get the stabalizing time. Adding a second FF shouldn't change that much. If it matters you have much more interesting problems. Am I missing something? -- These are my opinions, not necessarily my employeers. I hate spam.Article: 34179
>I am doing a prototype with a PCI interface and there isn't a prayer of >making it work at 25mhz bus transfer (my slowest machine available) >without a lot of effort. What would you do to easily slow things down? You could try slowing down the crystal on the CPU (without telling it). Here is a way to cheat. Put a PCI-PCI bridge chip on your board. It will meet the specs for the main PCI bus. Now comes the hard part. You have to read the PCI specs enough to understand their timing budget. They allocate x ns for the signals to get from one chip to another. That's a big part of the cycle. Since you just have the bridge chip and your chip on your own private PCI bus, you can use that "get to the other chip" time as extra setup time and/or to relax the clock-output time. You can get 10% or so by just making sure your VCC doesn't go low and that your chip doesn't get hot. -- These are my opinions, not necessarily my employeers. I hate spam.Article: 34180
Although 5V PCI bus can run at any frequency between 0 to 33MHz, I
believe 25MHz is the lowest frequency you can get from most
motherboards (old Socket 5/7 motherboards offered this option to
accommodate Pentium 75MHz), and in newer motherboards, 33MHz seems to
be the only frequency supported.
How much logic simulation did you do before firing up the PCI board?
If your logic simulation went okay, but the board doesn't work when
you put it into the system, then your design is likely not meeting the
timings of the PCI specification.
Tsu (Input Setup Time to CLK) has to be within 7ns, and Tval (CLK to
Signal Valid Delay) has to be within 11ns.
Although the maximum for Ton (Float to Active Delay) is not specified
(minimum 2ns), in my opinion, it will nice to get that to within 11ns
(same as Tval).
I recently fired up Insight Electronics Spartan II PCI
development board (http://www.insight-electronics.com/solutions/kits/xilinx/spartan-iipci.html)
with my own PCI IP core (I didn't use Xilinx's PCI IP core), and even
though the timing analyzer told me that some of the input signals
require around 12ns Tsu, and around 15ns Tval for output signals, the
board was recognized as a PCI device by the BIOS, and Windows 98
detected the PCI card automatically at startup.
This means that the PCI card with my PCI IP core worked even though
the timings were not being met.
The motherboard had 430TX chipset on it, and the PCI bus ran at 33MHz.
My theory that the reason PCI card worked is that the PCI card used
some of the Tprop (10ns. bus propagation time (the time signals travel
on the PCB)) to meet the Tsu/Tval requirements.
For the P&R (Place & Route), I used the the one that came with
WebPack, and used only a User Constraint File to specify the timings I
wanted.
Since the PCI card with my PCI IP core that violated the timings
worked okay at 33MHz, I will suspect that your problem is not the
timings, but with your state machine design.
Regards,
Kevin Brace (don't respond to me directly, respond within the
newsgroup)
Joey Oravec <joey@sun.science.wayne.edu> wrote in message news:<9lesog$f65$1@cwis-1.wayne.edu>...
> Hi, surely somebody else has run into this before.
>
> I am doing a prototype with a PCI interface and there isn't a prayer of
> making it work at 25mhz bus transfer (my slowest machine available)
> without a lot of effort. What would you do to easily slow things down? I
> know DINI group has a card for $600 that will halve the PCI clock and
> another for $3k which is more flexible. There's PCI-PCI bridge IP
> available but that's also expensive.
>
> Unfortunately I'm cheap and I'm thinking there must be a better
> inexpensive solution. Any thoughts?
Article: 34181Phil Hays wrote: <snip of perfectly reasonable paranoia, possibly not enough even> > > The reason why this happens is that some programmer in X-land added an > optimization to PAR for XC4000's that will add a duplicate FF if any time or > routing resource can be saved. This is good, if your design has a single > clock. This is very evil if you have multiple clocks. > > -- > Phil Hays ... it would have been nice if the said programmer, just before he/she was sent to "sleep with the fishes", had put some sort of message in the PAR report file. Parenthetically this is a living breathing example of why the idea that you can ``leverage'' cheap s/w resource using things like Handle-C is a BAD IDEA.Article: 34182
I created a test design to see what could be done. Here is a possible solution: 33MHz mhz goes thru IBUFG then BUFG to be your clk_33 Output of IBUFG also goes to DCM CLKIN DCM CLK2X goes to a BUFG, its output goes to CLKFB DCM CLK2X180 goes to a BUFG, its output is your somewhat delayed CLK_66 (assume that the two BUFGs are reasonabbly matched. Remember that you will be adding more loads to the CLK_66 net) I ran the design successfully through M3.3.08i Philip On Wed, 15 Aug 2001 14:06:36 -0400, "Jamie Sanderson" <jamie@nortelnetworks.com> wrote: >"Jamie Sanderson" <jamie@nortelnetworks.com> wrote in message >news:9ledgn$gb5$1@bcarh8ab.ca.nortel.com... > >> I think what I'll do is use the CLK2X180 output, instead of CLK2X. I think >> that allows me to use rising edge clocks everywhere, while providing a >> quarter clock period of setup/hold between the clock domains. > >Hmm, this gives me a mapper error > >ERROR:MapLib:326 - DCM symbol "dcm0" (output signal=slow2x_clk) CLKFB is not > >driven by the CLK0 or CLK2X pin of the same DCM. > >Errors found during the mapping phase. Output files will not be written. > >That's annoying... Back to the drawing board. > > Philip Freidin FliptronicsArticle: 34183
On Thu, 16 Aug 2001 06:20:32 -0000, hmurray-nospam@megapathdsl.net (Hal Murray) wrote: > >>We are working on a design in an XC4000 about 64K gates and are having a >>problem with register replication. The P$R tool is replicating a FF that >>is the critical element of a cross clock domain synchronizer. I call >>this a "bad thing". > >Did you spot this by eyeball? Or did you encounter a problem and track >it back? > >The normal synchronizer setup is a FF, a short wire, then another FF, >with both FFs running on the same clock. > >So I assume it replicated the second FF. I don't see any problem with >that as long as both wires from the first FF are short. I would >get uncomfortable if it put the second FF on the opposite of the chip. >(I'd be uncomfortable with that even if it didn't replicate the FF.) > >The idea is that the first FF may go metastable. If so, you have >most of a clock cycle for it to stabalize. You have to subtract >the setup time, the clock to output time, and the routing time from >the cycle time to get the stabalizing time. Adding a second FF >shouldn't change that much. If it matters you have much more >interesting problems. > >Am I missing something? Yes. The duplicated flip flops may settle to *different* values. Allan.Article: 34184
Even better www.asciimation.co.nz\beer Not sure what its got to do with embedded though... Russell Shaw wrote in message <3B7B401E.E90A0168@iprimus.com.au>... >http://www.asciimation.co.nzArticle: 34185
> >Am I missing something? > Yes. The duplicated flip flops may settle to *different* values. But if that happens, they one of them could just as easily have gone metastable and the whole point of this circuit is to leave enough time between FFs so that won't happen. -- These are my opinions, not necessarily my employeers. I hate spam.Article: 34186
This is a multi-part message in MIME format. --------------97A4A7D504C3D951F6037440 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Do any of you kown some good starting point for finding FPGA development boards. I have quite specific requirement such as PCI interface (or preferably PMC interface), onboard (or SODIM) SDRAM (> 32MB) and lots of user IO (in the range of 150 I/O). And I perfer using Xilinx. <p>Thanks <p>John <br> </html> --------------97A4A7D504C3D951F6037440 Content-Type: text/x-vcard; charset=us-ascii; name="john.daae.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John Content-Disposition: attachment; filename="john.daae.vcf" begin:vcard n:Daae;John tel;cell:99 59 00 70 tel;home:22 67 58 94 tel;work:67 11 20 89 x-mozilla-html:FALSE url:http://www.datarespons.com/ org:Data Respons AS;Project Department version:2.1 email;internet:John.Daae@datarespons.no title:Senior Utviklingsingeniør adr;quoted-printable:;;Ekebergveien 25 B=0D=0A0196 Oslo;;;; fn:John Daae end:vcard --------------97A4A7D504C3D951F6037440--Article: 34187
Hi there I'm trying to do readback (verify and capture) from Xilinx's Vertex devices. Does anybody have some experiences with it??? We send the signals and readback commands according to Xilinx's XAPP138 but unfortunately, the FPGA only replys with 0xf9f1f3ff and after this all 0xf9 ... Obvioulsy, this is no meaningfull readback data. Please help!! Thanx HerbiArticle: 34188
John wrote:
> Do any of you kown some good starting point for
> finding FPGA development boards.
http://www.optimagic.com -> Boards.
Lars
--
Address: University of Mannheim; D7, 3-4; 68159 Mannheim, Germany
Tel: +(49) 621 181-2716, Fax: -2713
email: larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/
Article: 34189Hi Can anyone tell me what the following pins are used for when they are not used as user IO pins: nCEO CS nCS nRS nWS DEV_OE DEV_nCLR INIT_DONE RDY_nBSY Thank You Andrew GrayArticle: 34190
On Thu, 16 Aug 2001 07:22:33 -0000, hmurray-nospam@megapathdsl.net (Hal Murray) wrote: >> >Am I missing something? > >> Yes. The duplicated flip flops may settle to *different* values. > >But if that happens, they one of them could just as easily have >gone metastable and the whole point of this circuit is to leave >enough time between FFs so that won't happen. Oops. I thought it was the first flip flop that was duplicated. The second one is safe as long as sufficient time is allowed, as you noted. Allan.Article: 34191
Joey Oravec <joey@sun.science.wayne.edu> wrote in message news:<9lesog$f65$1@cwis-1.wayne.edu>... > Hi, surely somebody else has run into this before. > > I am doing a prototype with a PCI interface and there isn't a prayer of > making it work at 25mhz bus transfer (my slowest machine available) > without a lot of effort. What would you do to easily slow things down? I > know DINI group has a card for $600 that will halve the PCI clock and > another for $3k which is more flexible. There's PCI-PCI bridge IP > available but that's also expensive. > > Unfortunately I'm cheap and I'm thinking there must be a better > inexpensive solution. Any thoughts? The safest option would be to get a motherboard that can be underclocked in BIOS. I've successfully used the Abit SA6R, setting FSB to 60 MHz, clock ratio to 4:4:1, resulting in 15 MHz PCI. Alternatively, you can check if you motherboard is supported by CPUCooL (http://www.podien.onlinehome.de/). It can change the PLL settings on many motherboard, even if the BIOS doesn't support that. Even better, it can be changed *runtime*, thus you can throttle your clock without rebooting in-between each attempt (as long as you don't lock up the system.....) Regards, - OlafArticle: 34192
In article <997947985.88785@nntp.up.ac.za>, "Andrew Gray" <s9813479@student.up.ac.za> wrote: >Hi > >Can anyone tell me what the following pins are used for when they are not >used as user IO pins: > >nCEO >CS >nCS >nRS >nWS >DEV_OE >DEV_nCLR >INIT_DONE >RDY_nBSY > >Thank You > >Andrew Gray > > > Hi Andrew Please tell me the supplier's name of this device, then I probably can help you! I've some experiences with Xilinx FPGAs. In this case, pins as CS means "Chip Select", INIT_DONE is used for clearing the device, etc. In general, some of the pins can be used either as configuration port or as general purpose/user pins. cu HerbiArticle: 34193
In article <3B7B750B.1C7D0C30@datarespons.no>, John <john.daae@datarespons.no> wrote: >This is a multi-part message in MIME format. >--------------97A4A7D504C3D951F6037440 >Content-Type: text/html; charset=us-ascii >Content-Transfer-Encoding: 7bit > ><!doctype html public "-//w3c//dtd html 4.0 transitional//en"> ><html> >Do any of you kown some good starting point for finding FPGA development >boards. I have quite specific requirement such as PCI interface (or preferably >PMC interface), onboard (or SODIM) SDRAM (> 32MB) and lots of user IO (in >the range of 150 I/O). And I perfer using Xilinx. ><p>Thanks ><p>John ><br> </html> > >--------------97A4A7D504C3D951F6037440 >Content-Type: text/x-vcard; charset=us-ascii; > name="john.daae.vcf" >Content-Transfer-Encoding: 7bit >Content-Description: Card for John >Content-Disposition: attachment; > filename="john.daae.vcf" > >begin:vcard >n:Daae;John >tel;cell:99 59 00 70 >tel;home:22 67 58 94 >tel;work:67 11 20 89 >x-mozilla-html:FALSE >url:http://www.datarespons.com/ >org:Data Respons AS;Project Department >version:2.1 >email;internet:John.Daae@datarespons.no >title:Senior Utviklingsingeniør >adr;quoted-printable:;;Ekebergveien 25 B=0D=0A0196 Oslo;;;; >fn:John Daae >end:vcard > >--------------97A4A7D504C3D951F6037440-- > Hi there Try out www.xess.com We use the XSV-800 board from XESS and we're happy with it... :-) cu HerbiArticle: 34194
In article <97fd5b24.0108150319.36203c19@posting.google.com>, jhmorris47@hotmail.com (Jason) wrote: >I'm just a newbie here and would like to know which FPGA would be best >suited for reconfigurable computing in terms of logic units, speed of >reconfigurability, etc. Any help would be appreciated. > >Thanks >Jason H. Morris Hi Jason Of course, it depends on what exactly you plan to do with your FPGA. I've some experiences with XILINX FPGAs Vertex Series. As you mentioned, you would like to do reconfiguration, these devices will be suitable for you. It's possible to dynamically and paritaly reconfigure, readback (verify and capture) etc. For more information, check out www.xilinx.com There are also some "cool" prototyping boards from XESS (www.xess.com) available. Hope this helps... :-) cu HerbiArticle: 34195
> Please tell me the supplier's name of this device The ACEX1K is an Altera device )RST(Article: 34196
Hi It is an Altera device: Acex EP1K100 "Herbi" <walder@tik.ee.ethz.ch> wrote in message news:3b7b8312$1@pfaff.ethz.ch... > In article <997947985.88785@nntp.up.ac.za>, "Andrew Gray" <s9813479@student.up.ac.za> wrote: > >Hi > > > >Can anyone tell me what the following pins are used for when they are not > >used as user IO pins: > > > >nCEO > >CS > >nCS > >nRS > >nWS > >DEV_OE > >DEV_nCLR > >INIT_DONE > >RDY_nBSY > > > >Thank You > > > >Andrew Gray > > > > > > > > > Hi Andrew > > Please tell me the supplier's name of this device, then I probably can help > you! > I've some experiences with Xilinx FPGAs. In this case, pins as CS means "Chip > Select", INIT_DONE is used for clearing the device, etc. > In general, some of the pins can be used either as configuration port or as > general purpose/user pins. > > cu > HerbiArticle: 34197
I like this guys jet powered beer cooler!!! http://www.asciimation.co.nz/beer On Thu, 16 Aug 2001 13:38:06 +1000, Russell Shaw <rjshaw@iprimus.com.au> wrote: >http://www.asciimation.co.nzArticle: 34198
hi, well, we will lose in terms of speed (till the half). what about using the highest frequency to drive all the logic, and just CE for the slower frequency ? (effect on power) Do Xilinx approve this problem ? are they planning to tackle it ? Regards In article <3B7AAEDB.47875520@xilinx.com>, Peter Alfke says... > >Since your two clock frequencies are fundamentally phase-coherent, albeit >perhaps with a certain unpredictable tolerance, you can cross the clock-domain >boundary simply by using the opposite edge of the higher frequency clock. This >does cut into your timing budget, but is safe otherwise. > >Peter Alfke > >Article: 34199
There is a Xilinx app note (vtt002) about using 5V devices with Virtex devices but it states explicitely that this does not work with Virtex-II. I need to connect some 5V AD devices to a Virtex-II. The ADs are TTL compatible so no pb to drive them from the Virtex-II but I have to read values form these ADs. So what are the solutions for this ? (small ones please...) Thanks Marc Battyani
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