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
Austin Franklin wrote: > You know, all this fancy (and expensive) "stuff" that you have to do to get > synthesized code to work "fast" is absolutely no effort to do with the > design correctly done using schematics as the entry methodology. Sigh. Absolutely no effort? Ho Ho. I've done schematics with floorplanning. I know better than absolutely no effort. Sure, if there are significant regularities in the design you can save some effort, yet you still need to plop down a lot of little shapes and connect little wires to each of them and label or connect each little wire. No effort? Ho Ho. And doing this for say 4,000 FFs, 5,000 LUTs, 1,200 luts used as memory and 72 block RAMs? That's a lot of little wires to attach. Then there is the floorplanning. It takes effort to attach each little RLOC or LOC to each little gate. Doing this for a 5000 LUTs might be easier if they are in some sort of regular array. What if they mostly not regular? And not just design entry. It takes effort to plan out a design, from the top level specification to the implementation. It takes effort to work out the details. It takes effort to verify the design by simulation. It takes effort to work through the timing issues. It takes effort to properly pass information between different clock domains. It takes effort to take the design into a reliable product. It takes effort to document the whole process so that others might be able to extend it in the future. I agree that some designs can be done with less effort with schematics. And if there was a good package that allowed mixed schematics and HDL, that might be a good choice for some designs. Yet the majority of designs are done in HDL for good reasons: less effort, better results. -- Phil HaysArticle: 34426
Hi all,
I have some problem with my design in Xilinx WebPACK. I need to count events
on an I/O pin. When I specify the pin number for counter clock signal in UCF
file, the map process generates error 93 .......IPAD-IBUFG should only be
LOCed to GCLKIOB site.
I tried to instantiate BUFGP and BUFGDLL primitives between the I/O pin and
internal clock signal but they may be used with GCLK pins only.
Is there any way to drive clock signal for counter by an general I/O pin?
Thanks for your help!
Regards,
Jan
___________________________
j.pech@sh.cvut.cz
+420 (723) 760802
ICQ: 56431283
Article: 34427Hi, Patrick Dano wrote: > Does anyone know how to associate pin location with pad location in Actel > FPGA's (ie, what pins are associated to what pads), specifically the > A500K130-456? The documents I have are missing some figures, and I cant > find anything on their web page. Try using the pineditor in the designer. bye Thomas -- Thomas Stanka Bosch SatCom GmbH BC/EMD4 D-71522 Backnang Tel. +49 7191 930-1690 Gerberstr. 49 Fax. +49 7191 930-21690 Zi. 10/528 Thomas.Stanka@de.bosch.comArticle: 34428
From VHDL you can only read files that you can specify as a path in your filesystem. So - to read a file from a Smartmedia card, requires a Smartmedia cardreader with a driver that supports your operating systems file system. If you can read the Smartmedia files from your file browser, you should also be able to read it from a VHDL file by specifying the same path as shown in your browser. Hope this helps. regards Martin "Andrew Gray" <andrew@tuks.co.za> wrote in message news:<998576679.227273@nntp.up.ac.za>... > Hi > > Does anyone know how to read a file from a SmartMedia card in VHDL? > > AndrewArticle: 34429
This is a multi-part message in MIME format. --------------2A7DBD766E28375B77F738DC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jan, Try this: IPAD--BUFG The IBUFG symbol suggests a dedicated clock pad. Jan Pech wrote: > Hi all, > I have some problem with my design in Xilinx WebPACK. I need to count events > on an I/O pin. When I specify the pin number for counter clock signal in UCF > file, the map process generates error 93 .......IPAD-IBUFG should only be > LOCed to GCLKIOB site. > I tried to instantiate BUFGP and BUFGDLL primitives between the I/O pin and > internal clock signal but they may be used with GCLK pins only. > Is there any way to drive clock signal for counter by an general I/O pin? > > Thanks for your help! > > Regards, > Jan > > ___________________________ > j.pech@sh.cvut.cz > +420 (723) 760802 > ICQ: 56431283 --------------2A7DBD766E28375B77F738DC Content-Type: text/x-vcard; charset=us-ascii; name="stephan.neuhold.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Stephan Neuhold Content-Disposition: attachment; filename="stephan.neuhold.vcf" begin:vcard n:Neuhold;Stephan tel;fax:+44 (0)870 7350 620 tel;work:+44 (0)870 7350 576 x-mozilla-html:FALSE url:http://www.xilinx.com org:Xilinx;Xilinx Technical Support version:2.1 email;internet:stephan.neuhold@xilinx.com title:Customer Applications Engineer adr;quoted-printable:;;203 Brooklands Road=0D=0A;Weybridge;;KT13 0RH;United Kingdom fn:Stephan Neuhold end:vcard --------------2A7DBD766E28375B77F738DC--Article: 34430
Usually, you should connect clocks to the dedicated clock inputs (there are 4). If you really want to connect a clock to a non-clock pad (which is only recommended if you have sufficient expirience) then you have to add some synthesis constraints that tells the compiler NOT to generate a IBUFG for your clock signal. I dont know how do do it in Webpack, because I use Foundation. Regards FalkArticle: 34431
<Falk> wrote in message news:ee7216f.1@WebX.sUN8CHnE... > Usually, you should connect clocks to the dedicated clock inputs (there are 4). > If you really want to connect a clock to a non-clock pad (which is only recommended if you have sufficient expirience) then you have to add some synthesis constraints that tells the compiler NOT to generate a IBUFG for your clock signal. I dont know how do do it in Webpack, because I use Foundation. > > Regards > Falk I instantiated the BUFG primitive into the top-level design file between the input pad (and of course the IBUF) and the internal clock signal. JanArticle: 34432
I wrote: > ------------------------------------------------------------------------ > I'm getting some warnings from MAP that I think are being caused by a > bum synthesis [Synplify] but I'm not sure, it might be a MAP > problem. > Yada, Yada, Yada ... I looks like I was wrong & its MAP shooting itself in the foot. Now off for several weeks to persuade Xilinx of this fact. Apologies to any Synplicity engineers herein present.Article: 34433
Martin Roenne wrote: > From VHDL you can only read files that you can specify as a path in > your filesystem. So - to read a file from a Smartmedia card, requires > a Smartmedia cardreader with a driver that supports your operating > systems file system. If you can read the Smartmedia files from your > file browser, you should also be able to read it from a VHDL file by > specifying the same path as shown in your browser. Hope this helps. > > regards Martin > > "Andrew Gray" <andrew@tuks.co.za> wrote in message news:<998576679.227273@nntp.up.ac.za>... > > Hi > > > > Does anyone know how to read a file from a SmartMedia card in VHDL? > > > > Andrew I suspect that the original poster wanted to know how to read data from a smart media card that is connected to an FPGA with some wires. The information on how to perform low level accesses to SmartMedia chips can be found in the data sheets of NAND-Flash manufactures. For example at www.amd.com. SmartMedia is not mentioned in the data sheet, but the protocol is the same. (An it is very simple, too) But to exchange data with other devices (PC, camera, ...) via smart media cards you need to implement the file system that is used by these devices. I know nothing about this, but I suspect that you can find it in the Linux kernel sources. It is probably a good idea to use a processor for the file system implementation. See www.fpgacpu.org. Kolja SulimmaArticle: 34434
Cant you read the file byte by byte ?? Yours B "Martin Roenne" <mar@tcelectronic.com> wrote in message news:c62dc1e0.0108232346.7aa0ff9@posting.google.com... > From VHDL you can only read files that you can specify as a path in > your filesystem. So - to read a file from a Smartmedia card, requires > a Smartmedia cardreader with a driver that supports your operating > systems file system. If you can read the Smartmedia files from your > file browser, you should also be able to read it from a VHDL file by > specifying the same path as shown in your browser. Hope this helps. > > regards Martin > > "Andrew Gray" <andrew@tuks.co.za> wrote in message news:<998576679.227273@nntp.up.ac.za>... > > Hi > > > > Does anyone know how to read a file from a SmartMedia card in VHDL? > > > > AndrewArticle: 34435
> > You know, all this fancy (and expensive) "stuff" that you have to do to get > > synthesized code to work "fast" is absolutely no effort to do with the > > design correctly done using schematics as the entry methodology. Sigh. > > Absolutely no effort? Ho Ho. I see you have a second job around XMass time and are getting some practice in. It's three "Ho"'s by the way. > I've done schematics with floorplanning. I know better than absolutely no > effort. Yes, but I said "correctly done" ;-) One can do a bad job at anything. Do you have a library of preplaced and mapped symbols that give you most any permutation of data path elements you would need (counters, timers, registers, I/O, muxes etc.)? If not, then you really aren't setup correctly, now are you? > Then there is the > floorplanning. It takes effort to attach each little RLOC or LOC to each little > gate. No effort at all, that is already done for the elements in your library...oops, I forgot...you don't have a library? > And not just design entry. It takes effort to plan out a design, from the top > level specification to the implementation. It takes effort to work out the > details. It takes effort to verify the design by simulation. It takes effort > to work through the timing issues. It takes effort to properly pass information > between different clock domains. It takes effort to take the design into a > reliable product. It takes effort to document the whole process so that others > might be able to extend it in the future. And this has nothing at all to do with your design methodology at all. > I agree that some designs can be done with less effort with schematics. And if > there was a good package that allowed mixed schematics and HDL, that might be a > good choice for some designs. Ah, there is, and has been for a long time. It's called ViewDraw. > Yet the majority of designs are done in HDL for > good reasons: less effort, better results. You have no proof of this. That is absolutely pure myth. Have you actually done the same design in schematic and HDL and compared the effort and results? I have no doubt that there are SOME designs that MAY be implemented quicker in HDL, but I believe that is many many less than people believe. There are MAJOR political/business/ego reasons that there is a LOT of press/push for use of HDLs...and none for schematics. There is a lot of money to be had if you can convince people that HDLs are "the way to go"...whether it's true or not isn't important.Article: 34437
"Ben Franchuk" <bfranchuk@jetnet.ab.ca> wrote in message news:3B83BFE7.944667A6@jetnet.ab.ca... > James Lee wrote: > > > > I reviewed the book. It was quite interesting, I did not fully > > understand it untill I spoke with the authors. The focus is on > > picking a set of tools and libraries that work consistently with a > > style of verilog. > > > That sounds bad for the state of hardware development. Bugs in my > code/schematics I can correct, yet with the fact that the final output of logic > synthesizers is totally hidden from the public how do I know if there are no > bugs in the system. > Ben. It's not hidden, Ben, it's just in a different form. The way you know it's the same is twofold: first, you have a testbench you can run on the synthesized result, which should produce the same results as your original code. Second, you have formal verification tools, that can compare the synthesizer output (gate level verilog, in the case I'm familiar with) with your original VHDL or verilog code. -- Mike --Article: 34438
Hi, I'm looking for VHDL example of a set-associative mapping. Is anyone who can help me? Thanks in advance, Artur. kacorsz@wp.pl P.S. I'm also looking for some papers about software/hardware partitioning, especially using simulated annealing algorithm. If someone can send me them, I'll be grateful.Article: 34439
This is a multi-part message in MIME format.
--------------F37237A7D0AA334821D5B917
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello Kevin,
If you are using one of the newer versions of ModelSim, 5.5 or better, then
there are some new Verilog-2001 constructs that do make reading and writing to
files much easier than in the past. I have just started to play with it myself
so I am no expert but try looking into the $fscanf function. It has much more
flexibility than the more traditional $readmem functions. Here are some
relevant lines from my latest testbench to help you get started:
data_file = $fopen("../input_data.dat", "r"); // Open file for reading
$fseek (data_file, 102, 0); // Skip over some documentation at top of file
$fscanf(data_file, "%b", a_data); // Grab some data and store to reg called
a_data (binary in this case)
$fclose(data_file); // Close file
This is working quite well for me so far but again, just getting started with
this. If you are using another simulator, ask if there is Verilog-2001 support
or else the above constructs are invalid.
Good luck,
-- Brian
Kevin Neilson wrote:
> For testbenches, is there a method to read in a text file in Verilog? The
> $fdisplay function is great for writing to files, but the functions for
> reading in files are limited; the only method I know of to read in a file is
> to dump it into a register using the $readmemh command. However, that only
> works with files formatted in ascii-hex, e.g. "41 42 43", not files
> formatted in text, e.g. "ABC". I wrote a Perl script to convert text files
> to ascii-hex but that seems a lame workaround.
>
> -Kevin
--------------F37237A7D0AA334821D5B917
Content-Type: text/x-vcard; charset=us-ascii;
name="brian.philofsky.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brian Philofsky
Content-Disposition: attachment;
filename="brian.philofsky.vcf"
begin:vcard
n:Philofksy;Brian
x-mozilla-html:TRUE
org:Xilinx, Inc.;System Level & Alliance Marketing
adr:;;;;;;
version:2.1
email;internet:brian.philofsky@xilinx.com
title:Technical Marketing Engineer
fn:Brian Philofksy
end:vcard
--------------F37237A7D0AA334821D5B917--
Article: 34440Dave, Thanks! Austin Dave Vanden Bout wrote: > Austin Lesea wrote: > > > John, > > > > Make, model number, and where to buy the IR temp sensor? > > > > I get sooo many questions, and it would be worth its weight in gold to publicize this > > info! > > You can buy an Extech infrared thermometer from Techni-tool for $99.00. Measures 0 - 600 > degrees F with a 6:1 field view. > > > > > > > Austin > > > > John Larkin wrote: > > > > > On Mon, 20 Aug 2001 19:10:26 +0100, Rick Filipkiewicz > > > <rick@algor.co.uk> wrote: > > > > > > >Peter, > > > > > > > >On top of all the other useful stuff you contribute to CAF you have just answered a > > > >long-standing (or burning ?) question of mine regarding the calibration of heat > > > >sensing fingertips. > > > > > > Peter, > > > > > > my right forefinger is calibrated as follows: > > > > > > 50C - ok for infinite duration contact > > > > > > 52C - 10 seconds to pullaway > > > > > > 60C - 1 second to pullaway > > > > > > Interpolate linearly between points. Your digits may vary. > > > > > > We just got a cheap ($79) infrared temp sensor, which is cool (no pun, > > > really) for scanning FPGAs on a board. > > > > > > John > > > > > > > > > > >To go further and get another data point: Last summer I was wondering why our new > > > >board wasn't doing anything from power-on. I, very briefly, put my finger on it & > > > >came away with a large & painful blister that was still very sore 2 days later. > > > > > > > >Cause = BGA chip pinout mirrored (not by me I hasten to add). > > > > > > > >What temp do you think the package would have reached ? > > -- > || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || > || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || > || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||Article: 34441
Ben Franchuk wrote: > > > It's not hidden, Ben, it's just in a different form. The way you know it's > > the same is twofold: first, you have a testbench you can run on the > > synthesized result, which should produce the same results as your original > > code. Second, you have formal verification tools, that can compare the > > synthesizer output (gate level verilog, in the case I'm familiar with) with > > your original VHDL or verilog code. > > Since I use free tools I don't have access to the fancy tools. Further proof of the old adage, "you get what you pay for." -aArticle: 34442
Philip Freidin wrote: > > > By the way Andy, did we really need for you to include his whole post ? :-) I was so angry and annoyed and upset and pioughed that I neglected to use the magic "delete" function. Must be this Macintosh I'm workin' on... ---aArticle: 34443
Kevin Neilson wrote: > > For testbenches, is there a method to read in a text file in Verilog? The > $fdisplay function is great for writing to files, but the functions for > reading in files are limited; the only method I know of to read in a file is > to dump it into a register using the $readmemh command. However, that only > works with files formatted in ascii-hex, e.g. "41 42 43", not files > formatted in text, e.g. "ABC". I wrote a Perl script to convert text files > to ascii-hex but that seems a lame workaround. Do a Google search for "Verilog fileio." I don't remember off-hand what the exact url is, but this PLI is pretty much what you're looking for. Most, if not all, of its functionality is in Verilog-2001 but tool support is not clear. It works on a Solaris box. No idea if it works on Windows. BTW: you may want to post this in comp.lang.verilog... -aArticle: 34444
Hi all, I'm playing with XC2S200-PQ208, WebPack 3.3W8 and homemade parallel cable (74HC125 x 2). I ground PROGRAM pin, DONE goes low. I program the chip without verification, DONE goes high. Verify fails always in same place (frame 2000+). Docs (ds001_2.pdf, page 13) say that if DONE goes high device should be configured OK. Does all that mean that even if bitstream was received OK, the chip is fried and cannot be programmed? How important is to have 12 sets of 0.1/0.01uF caps, one on each power/ground pair? What else could go wrong? I have nothing else connected to the chip, just JTAG, M0-M2 jumpers, PROGRAM pullup and DONE LED, and all power/ground pins. I/O is floating.Article: 34445
Thanks Jan & Rick, I found a verilog model at micron that should help. Dave "Jan Pech" <j.pech@sh.cvut.cz> wrote in message news:9m3ivb$mub$1@ns.felk.cvut.cz... > Very good description of DRAM modes, access etc. can be found in Micron's > datasheets (http://www.micron.com). > > Jan > > > Hi All, > > > > I can read and write data using a fpga and dram but have no information on > > how to use the burst mode. > > Has anyone got any information that could help me? > > > > I know that I need to change the mode and then assert the burst command > but > > do not have any of the mode information. > > > > Intel used to have a good page but it has since been removed and I never > > downloaded the pdf (DOH) > > > > > > Cheers in advance > > Dave > > > > > > > > > >Article: 34446
Doh! I imagine that the request is for finite autonoma that implements a SmartMedia interface protocol... SmartMedia format has been released to the public. There is/was a SSFDC forum that you can join to access the latest specifications. try www.ssfdc.or.jp btw, SmartMedia is a trademark of Toshiba Corporation. "Andrew Gray" <andrew@tuks.co.za> wrote in message news:998576679.227273@nntp.up.ac.za... > Hi > > Does anyone know how to read a file from a SmartMedia card in VHDL? > > Andrew > >Article: 34447
Speedy Zero Two wrote: > Thanks Jan & Rick, > > I found a verilog model at micron that should help. > > Dave > Sorry, I should have mentioned the sim models as well. They're pretty good too, the only thing they really lack is a refresh period check - or at least the ones I downloaded a long while back.Article: 34448
On Tue, 21 Aug 2001 17:14:00 GMT, 101551.3434@compuserve.com (Mark Taylor) wrote: >On Tue, 21 Aug 2001 10:41:04 +0100, "Tim" <tim@rockylogic.com.nospam.com> >wrote: > >>"Mark Taylor" <101551.3434@compuserve.com> wrote in message >>news:3b816b86.32685097@news.compuserve.com... >> >>> 1) Is the access time / CLOCK to DOUT time for the BRAMS faster when set >>> for a wide data configuration? >>> (ie presumably the output signals can skip 4 levels of multiplexers) >> >>Most likely you get the muxes (pretty fast pass-transistors?) anyway. >> >Yes but they will be mainly switched off ( and so not contributing much to >delays) >or switched on and contributing say 80 ps for 4 layers or less for fewer. >Since the BRAMS are synchronous, they might go through a final layer of FFs. >(in which case I am surprised that the Tbcko is so high, ~3ns on -6 grade) >(if they do , then obviously the MUXES won't contribute at all to Tbcko) > >The probable difference is that for a NARROW Data width configuration, >the setup time for some address lines (which only control the muxes) might be >vey much less than that for other address lines (which have to go through the >physical RAM as well). > >What I wanted to do was to have deliberately skewed clocks such that much of >the fixed delays are effectively eliminated, but I wanted to be sure that the >delays would not have appreciable skew between the data bits. >There is also the issue of the net delays for routing, and whether these can be >modelled as primarily TRANSPORT or INERTIAL. >I want to aggressively maximise throughput, but not at the expense of >unreliability. > >Look at the timing specs for the BRAMs. >If you are just reading from them, then they can probably coast along at >250MHz+. >The Tbcko + net delay +? +setup time might add 7nS for one path. >If this were all transport delay, it would be possible to read imposing no >limit on operating frequency. >BUT if another path only took 1nS, then there would be a slight problem. >There's a skew of 6nS, which at a clock rate of 166Mhz would mean that the >pipeline would be completely screwed up. >Fmax would probably be reduced to 80MHz or so.... >This is a somewhat extreme case, but the difference between 80MHz & >250 MHz is enormous. >So I need to know how severe these skews are. >( and no, I'm not asking for 250Mhz!) > > > > > >>> 11)The P&R tools seem to consider (single port) RAM address lines to be >>> unswappable. >>> Is there any way around this, because almost invariably I find that >>> swapping (ie deleting net pins then adding net pins) >>> the two highest net delay address inputs improves the timing on BOTH lines. >> >>Be grateful that these lines aren't swapped when used as SRL delay values... >> >> >> >> >Actually that wouldn't matter, as long as I knew about it! >I would use the SRL's as a convenient way of reprogramming the contents of a >LUT. >This would only be sensible where most of the bits change and where the >update rate is less than a MHz, because 16 ~ is 16~. >I would be mainly using RAM16s to update those LUTs where only 1 or 2 bits >change, and where the update rate is higher. > >I can see that for complex cells integrating RAM with the multiplier AND's the >scope for pin swapping is less, but would still be there. >(just upper 2 bits and/or lower 2 bits) > >Even dual port is ok, as long as the F & G lines have equal swaps. >So, the question is how do I automate the procedure of reducing the maximum net >delays? (manually using FPGA_EDITOR is just not on ..) > > > > Dear Sir, My local telephone exchange has had a problem recently so I have had no internet access over the last few days. Even now the connection is at 16Kbaud! I had intended to send the text below somewhat earlier, but at least the delay allowed me to notice a program distributed with ISE 3: speedprint. I wasn't able to find any references to it, but it does seem to allow reports for best/worse case timing specifications for many devices. So consider questions 6 & 7 to be already well answered by Xilinx! >Message text written by INTERNET:peter.alfke@xilinx.com >> >Mark, the reason I did not answer has to do with the large number of different >questions, packaged together. I cannot answer them all, so I answered none. > >Here is the incomplete set of answers I got from a colleague: >Some answers > >> 1) Is the access time / CLOCK to DOUT time for the BRAMS faster when set >> for a wide data configuration? >> (ie presumably the output signals can skip 4 levels of multiplexers) > >no clue, but the speeds files would tell you (ie timing report) > Yes but only one Tbcko is reported by the software. I was interested in the timing of the hardware. I don't believe that there aren't any differences between either the clock to data for all data lines for all configurations, or the address to clock setup for all address lines for all configurations. I could be wrong, should the BRAMS contain a large number of FFs to synchronise all lines. The matter might be irrelevant, such as only a few pS difference, which would get swamped by the net delays. The net delays might be INERTIAL, in which case the swamping would be more. >> >> 2) is the carry out pin of a CLB in a LOW/HIGH/TRI STATE if not selected to >> be used in a 1 CLB hard macro? > >all logic is on, or off. even the tbufs are not tristate > Makes sense, obviously bad for CMOS lines to be floating within high speed logic. So I can initialise a carry chain even when the BX input is being used for something else? >> >> 3) whats the point of the CIN pins in the lowest row of slices? >> (ie with highest row index) > >No idea. I do know that signals that don't go anywhere are tied off by the >special term cells that go all around the clb array > I never understood about the tie-points for the 4000 series. Neither did the software. >> >> 4) if the answer to the 3rd question is NONE then you might be amused >> to try smart-placing (within FPGA_EDITOR) a hard macro which uses a >> CIN (seems to like the lowest row for some reason!) > >so what happens? > I stopped using "smart-placing". > >> 5) The Spartan2 databook is very unclear about IO banks & PQ packages. >> Presumably the Vref & Vccio arrangements are as with the Virtex? >> (which was at least clearly documented) > Sorry , unclear question. What I should have written would be: I understand that within the Virtex devices there are 8 I/O Banks, each potentially with their own Vccio & Vref lines. Within some packages the Vccio lines for different banks are bonded together . The exteme case is with the HQ/PQ packages, with just 1 Vccio line, but still with independent Vrefs. I guess that the same applies for the Spartan2, but if I hadn't seen the Virtex documentation I might not even have made that guess. Am I correct in assuming independent Vrefs for the Spartan2 PQ packages? >spartan is always more io bonded out, with fewer vcc's and gnds. if you want >performance, then you buy Virtex. If you want low cost, you buy Spartan II. > I want high processing performance and (generally) low I/O data rates. Hardly any of the OBUFS will be set to FAST, so I won't be ground bouncing. Spartan2-6 is the most cost effective solution. (better performance than Vertex-5 ) >> >> 6) Any chance of filling in some of the blank fields for Spartan2 -6 >> timing? > >don't know. ask Robert Wells. > Who is Robert Wells? is he accessible via robert.wells@xilinx.com ? >> >> 7) How about guaranteed best case timings as well ? >> ( specifically for BRAM access) > >some day > Sorry It's just that I could have sworn that Xilinx indicated the availability of this data several months ago.The indication was in tabular form. >> >> 8) Would it be possible to sacrifice a BRAM & use a DLL to lock onto the >> Tbcko , or would the delay of other BRAMS not track? (even though being >> guaranteed to have the same Vccint & presumably approximately the same >> temperature?) (bearing in mind question 1, I would only be applying this to >> identical >> data width BRAMS) If this approach is possible which data bit should I route >> through? > >BRAM and DLL are completely different animals, and I doubt they would track >with process/voltage/temperature > I meant having a clock from the output of a 2xDLL fed by the output of a BRAM whose sole duty is to toggle 1 output bit per input clock cycle. I.e. sanitising a dirty source in a highly controlled manner. The delay between the two clocks would depend on Tbcko. > >> 9) Do the industrial versions draw more startup current than the commercial >> devices at any given temperature, or is it only at extremely low >> temperatures (below the commercial range) that the current increases? > >just below 0C OK, so this should never be a reason to NOT select an Industrial part.. > >> >> 10) Using XST VHDL (SP8, on both WebPACK & ISE3.3i) RLOCS are lost on >>all but >> the first instance of a component containing RLOCS. This is BAD , especially >> when Carry logic and / or MUXF5 is involved, because what creeps into the >> wrong CLB makes no sense at all (as regards timing/space) . I originally >> thought this was a problem with MAP, but then examined the EDN file & >>found >> that MAP hadn't been told to cluster components within a CLB. (for any except >> the first instance) >> "Preserve Heirarchy" had been SET (as a synthesis option). Presumably the >>only way around this is to use "Incremental Synthesis"? (Apart from hacking >> the edn file to ensure all instances refer to the first cell definition,which >> does indeed work, but surely can't be considered a standard flow!) but >> incremental synthesis doesn't work for any OTHER component! I haven't tried >> using the XILFILE attribute which could be a way to enforce the correct >> hierarchy. > >This is a software question, right? I don't do software. > Sorry. I thought it was a bug report ! >> >> 11)The P&R tools seem to consider (single port) RAM address lines to be >> unswappable. Is there any way around this, because almost invariably I >> find that >> swapping (ie deleting net pins then adding net pins) the two highest >> net delay address inputs improves the timing on BOTHlines. > >There may be a dedicated route reason why this isn't allowed. I just don't >know. > It is allowed, but the tools don't do it themselves. I'll try pretending to MAP that the RAMs are LUTs, then patch the file after it has been routed. The P&R is very good about swapping LUT inputs to improve timing. The difficulty will be in ensuring all placement info gets through the tool chain. I'd pity someone targeting the xc2v10000 & using XDL. >> >> 12) Any chance of a job at Xilinx? (I can write tools. I can design hardware. >> I like Xilinx hardware.) I'm afraid that jobs locally to me are of the sort >> "You've got to use ACTEL" (probably something to do with the name of their >> main product line.) or "You've got to use Virtex" ( note not Virtex-E, >> Spartan2 or Virtex2 but Virtex). or "You've got to use ALTERA" or "You've >> got to have marketing experience". I can supply the names of the guilty >> parties, but I don't think that would help. > >There is always a chance. Got a resume? I can't say that it is a good chance, >or if it is a bad chance, but there is a chance, yes. > Ok, I'll just delete the section in which I indicate my bitterness as regards some versions of Xilinx software! >----------------------- Internet Header -------------------------------- >Sender: peter.alfke@xilinx.com >Received: from newsgate.xilinx.com (unknown-60-204.xilinx.com [149.199.60.204]) > by siaag2ae.compuserve.com (8.9.3/8.9.3/SUN-1.12) with ESMTP id QAA07396 > for <101551.3434@compuserve.com>; Tue, 21 Aug 2001 16:39:06 -0400 (EDT) >Received: from cliff.xsj.xilinx.com (cliff [149.199.38.103]) > by newsgate.xilinx.com (8.11.3/8.11.3) with ESMTP id f7LKctT08896 > for <101551.3434@compuserve.com>; Tue, 21 Aug 2001 13:38:56 -0700 (PDT) >Received: from newman.xilinx.com (newman [149.199.37.215]) > by cliff.xsj.xilinx.com (8.11.3/8.11.3) with ESMTP id f7LKcbf07993 > for <101551.3434@compuserve.com>; Tue, 21 Aug 2001 13:38:37 -0700 (PDT) >Received: from xilinx.com ([149.199.5.189]) by newman.xilinx.com > (Netscape Messaging Server 4.15) with ESMTP id GIFQOT00.TFE for > <101551.3434@compuserve.com>; Tue, 21 Aug 2001 13:38:53 -0700 >Message-ID: <3B82C6F9.B425883E@xilinx.com> >Date: Tue, 21 Aug 2001 13:39:21 -0700 >From: "Peter Alfke" <Peter.Alfke@xilinx.com> >Reply-To: peter.alfke@xilinx.com >Organization: Xilinx >X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) >X-Accept-Language: en >MIME-Version: 1.0 >To: Mark Taylor <101551.3434@compuserve.com> >Subject: Re: Some questions about Spartan2 (& a bug report for XST sp8) >References: <3b810b5a.8061400@news.compuserve.com> >Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" >Content-Transfer-Encoding: 7bit enc: monstercved3b.docArticle: 34449
On Fri, 24 Aug 2001 00:19:48 GMT, arast@inficom.com (Alex Rast) wrote: >This is one I think I've done before, so I probably just need my memory >jogged. I'm sure it's something that happens, and that you need, all the time. > >I've defined a hard macro, call it custommacro.nmc. This macro will have >internal routes and external macro pins (not the pins/I/O pads of the device, >the logical pins of the macro). Now, at least one of the nets connects to an >external pin and an internal route. One common example, for instance, is CLK. >You want the signal to be common to the internal CLB's of the macro and to >connect to external routes (in the case of CLK, to the global clock net). > >Now, within the macro I define a proper external pin for the clock net, >attaching it to one of the CLK pins for a slice. Then I instantiate the macro >in the design within FPGA editor. So now I go to route a net, for instance the >global clock net, to the appropriate external pin on the macro, thus >connecting the external signal to the internal macro net. What I do is >highlight the macro pin I want, and all segments of the external net I want to >route. Then I click the route button. > >No success. FPGA Editor complains "WARNING:FPGAEditor: 145 - Cannot add to net >"Macro1CLK" -- it is an internal macro net." > >What am I doing wrong? Is it an error in how I've defined the external pins in >the macro? Using the wrong procedure to route the external nets? Or something >else? This situation must surely be pretty common (clock signals, in >particular, are almost always going to have to be common to internal routes in >a macro and external routes) so I think I'm missing something. As I say, I >think I've solved this problem before. But in any event, can someone give me >the basic idea of what to do? > >Thanks. > >Alex Rast >arast@inficom.com >arast@qwest.net As far as I know, nets could never be included in hard macros. (despite documentation suggesting otherwise, right back to before EPIC) Just use the hard macro to configure slices/CLBs or whatever, then embed the macro within a soft macro (ie a schematic macro with RLOCS). The soft macro can contain all the routing. You will need to use FILE= thingy.nmc, ( or XILFILE=thingy.nmc if you have to go through VHDL) as an attribute for the symbol associated with the hard macro. Mark Taylor Mark_Taylor_Chess@compuserve.com
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