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
Uwe Bonnes wrote: > How do other people handle this problem. The UCF file assemble requirements > form two different areas: Things like timing and things like Pin > assignments. Pin assignment needs to be generated from layout files and > may change often. As I don't know of a way to include something in the UCF > file, the UCF file needs to be carefully edited each time the pin assignment > changes. If there would be a possiblity to include something in the UCF > file, the pin assignment could be generated in a seperate file, the include > in the UCF could point to that file and changes would get picked up > automatically. > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- I generally merge the necessary parts by hand. I keep a version of the LOC directives for a particular board without any timing constraints, then add the timing constraints for any particular project using that part. Since we generally have printed circuit layout before the FPGA code is final, I don't usually have the issue of pinout changing for the same FPGA design, but I will have multiple FPGA designs for the same board layout. One note. I NEVER use the GUI tools to create constraints. They totally screw up the UCF file. They re-arrange the pin order and remove comments. I ALWAYS save a backup copy of the UCF in case I unintentionally open the UCF with the GUI tools. This is easily done if you double-click the ucf file from the Project Navigator, instead of right click and selecting edit constraints (text). Just My 2 cents GaborArticle: 108776
hi.
well thanks for all the help with my previous problem.
of course i ran into another one already....
i have the following c code:
#include "xmk.h"
#include "stdio.h"
#include "lwip/api.h"
#include "xparameters.h"
int main()
{
xil_printf("\r\n\r\n\r\nEntering main \r\n");
xilkernel_main();
return 0;
}
void* system_setup(void* arg)
{
xil_printf("Initializing lwIP .");
lwip_init();
xil_printf(" done. \r\n");
return 0;
}
i still get the "Initializing lwIP" output but then the programm never
come back from the lwip_init() function.
where is the funcion defined anyway? (what source file)
any hints?
thanks
Article: 108777Jim, The problem is perhaps a bit more complex than you are suggesting. We have customers that require the parts to configure very fast, basically at the maximum CCLK rate in the data sheet. That said, those clocks require SI engineering. Since some folks require high speed, and others do not, what compromise can we make? Do we put the circuits in the chip and slow the edges down, schmidt trigger with extreme hysterisis, and just wqalk away from another set of customers? That doesn't work. Can we program the CCLK pin's behavior? No, because this is a "chicken and egg" problem (have not read in the bitstream, yet. If you have a solution, I am listening. So, rather that characterize my response as callous, unforgiving, and elitist (which some have seemed to do), it should be seen as "these are the simple facts." It is a high speed interface (because people do use it there), so if you use it at very low clock rates, you will still need to do the necessary singal integrity engineering. And, if you do not have a tool to do it, our hotline will do it for you, for free. (I have said this many times before). We will also suggest you invest in an SI tool (my favorite is Mentor's Hyperlynx), which will pay for itself when you do not have a pcb respin, once, due to better SI engineering. I am apalled that people who call themselves 'engineers' (not referring to you, of course) would completely ignore physics, and continue to act as if there is no such thing as signal integrity, and continue to waste their company's money by not doing something that they should be doing (not just for CCLK, but all the other IO pins on the package, too). Austin From spampostmaster@comcast.net Sat Sep 16 08:59:10 2006 Path: newsdbm05.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 16 Sep 2006 10:58:49 -0500 From: Phil Hays <spampostmaster@comcast.net> Subject: Re: How to handle UCF file Date: Sat, 16 Sep 2006 08:59:10 -0700 User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2006.09.16.15.59.09.834692@comcast.net> Newsgroups: comp.arch.fpga References: <eegva9$m9o$1@lnx107.hrz.tu-darmstadt.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 24 NNTP-Posting-Host: 24.16.63.21 X-Trace: sv3-UPzPjf+qYjFx6MypLFLtI5SZXB+oKgQqMfeSZQd/jjpEG4QpJPq/ZmFu6ImWg55SU6mIu5g9qa6eZaP!JlLd/wHcvruYHL4x/IjdvFP4ST22Z/+lLDrVZTTxT7pwswmSH5UtboDpXvMi/5r7fUQ76SnszFke!bfNBsw== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: prodigy.net comp.arch.fpga:119675 Uwe Bonnes wrote: > How do other people handle this problem. The UCF file assemble > requirements form two different areas: Things like timing and things > like Pin assignments. Pin assignment needs to be generated from layout > files and may change often. As I don't know of a way to include > something in the UCF file, the UCF file needs to be carefully edited > each time the pin assignment changes. If there would be a possiblity to > include something in the UCF file, the pin assignment could be generated > in a seperate file, the include in the UCF could point to that file and > changes would get picked up automatically. If you use a gnu make makefile (or script based build0, you can do this now, try something like: mkdir -p ../bld/ rm -f ../bld/temp.ucf cat pinout.ucf core1.ucf core2.ucf timings.ucf > ../bld/temp.ucf cd ../bld/ && ngdbuild blah -uc temp.ucf blah blah -- Phil HaysArticle: 108778
joseph2k wrote: > > And if i have followed the story aright, Ernie reaped the "full benefit" of > what he had sown. If you call having to move out of the state to find another job "full benefit", well, yes. He deserved more than he got, but he would never find work in that part of Ohio in a similar position, again. That, plus the business we worked in generally knew about bad apples, because the word spread fairly fast. When a system manager either quit or was fired, it was obvious that something was wrong with them. If they didn't like where they were at, they would line up another job first so it would appear that it was their choice to move on. On the other hand, when the trade journals printed a blurb that "company ABC" has hired a new manager to replace "XYZ" who quit without notice, people know that something is wrong with the individual. -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central Florida From spampostmaster@comcast.net Sat Sep 16 09:14:53 2006 Path: newsdbm05.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!nx02.iad01.newshosting.com!newshosting.com!216.196.98.140.MISMATCH!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 16 Sep 2006 11:14:32 -0500 From: Phil Hays <spampostmaster@comcast.net> Subject: Re: How to handle UCF file Date: Sat, 16 Sep 2006 09:14:53 -0700 User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Message-Id: <pan.2006.09.16.16.14.50.207613@comcast.net> Newsgroups: comp.arch.fpga References: <eegva9$m9o$1@lnx107.hrz.tu-darmstadt.de> <pan.2006.09.16.15.59.09.834692@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Lines: 30 NNTP-Posting-Host: 24.16.63.21 X-Trace: sv3-5Jtfe/f1l14GHIjJz3MrkEsBNQl388G0zUyooETs3mBFoyahoxxA0r5PBcTS1w7iHMu+odY6boFBbYs!Wj8piCoJ12Ry2RfgUJix+ii7tHzRGrqCl9Aw1BrcTmOzXP5l11Q3vtB9pgnPyJU5LZFUJMj9iW8G!i/+A0w== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: prodigy.net comp.arch.fpga:119677 Phil Hays wrote: > Uwe Bonnes wrote: > >> How do other people handle this problem. The UCF file assemble >> requirements form two different areas: Things like timing and things >> like Pin assignments. Pin assignment needs to be generated from layout >> files and may change often. As I don't know of a way to include >> something in the UCF file, the UCF file needs to be carefully edited >> each time the pin assignment changes. If there would be a possiblity to >> include something in the UCF file, the pin assignment could be generated >> in a seperate file, the include in the UCF could point to that file and >> changes would get picked up automatically. > > If you use a gnu make makefile (or script based build0, you can do this > now, try something like: > > mkdir -p ../bld/ > rm -f ../bld/temp.ucf cat pinout.ucf core1.ucf core2.ucf timings.ucf > ../bld/temp.ucf cd ../bld/ && ngdbuild blah -uc temp.ucf blah blah Now how did that "cd" get on the wrong line?? Code typo corrected. -- Phil HaysArticle: 108779
Ran across this board the other day, was wondering if anyone has any experiences with it, good or bad. Also, not really being too experiences in sizing yet, would something like this be big enough for a complete system, using a leon sparc or similar sized core? it seems to have the basic features i want, ethernet, vga, serial, ram, reasonable cost, etc.. But if it is too small to be useable for SOC type projects, it wont help me much. http://www.embeddedarm.com/epc/ts7300-spec-h.htmArticle: 108780
Uwe Bonnes schrieb: > Antti <Antti.Lukats@xilant.com> wrote: > > > I am trying it right now - seems like lot of fun, when trying it with > > Xilinx ISE it has already managed to make 3 different kinds of fatal > > crashes !! > > > so it would be good test case for Xilinx to test their software > > against. > > Well, do you have the impression that the ISE programmers test their > software and have a regression test suite? > > For example they claimed the Impact crash on Linux when reloading a > bitstream/jedec file fixed, obvious it wasn't, as easy test showed (Xilinx > Answer #23745). Or if you look at the still unsilved VLGINCDIR problem > Answer Record # 17027. It worked in some ISE 6 version, but was broken in > ISE 7 again. > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Uwe, Xilinx defenetly has a regresion test suite. But in the context of their software management this only means that their software doesnt fail on the regression suite, and may fail and often does an any other design. No matter how many bugs they fix, new bugs come or re-appear in even bigger number so the overall software quality isnt improving. OTOH it depends on the metrics - I have one simple measurement TTFFC - time to first fatal crash (from fresh install) ISE 8.1 - 3 minutes ISE 8.2 - 8 minutes so by that metrics we have ISE 8.2 software quality improved by 250% over ISE 8.1 so it all depends :) and to Xilinx, yes please take this seriously. AnttiArticle: 108781
Uwe Bonnes schrieb: > Antti Lukats <antti@openchip.org> wrote: > > "ziggy" <ziggy@fakedaddress.com> schrieb im Newsbeitrag > > news:ziggy-E12AF3.19422315092006@news.isp.giganews.com... > > > Ok, so a link to these people came across my mail box today. and its > > > supposedly a Open Source 64bit sparc core.. > > > > > > Anyone that has seen this before want to comment? > > > > > > Oh, and the little piece of hardware they show on their pages, anyone > > > know what that is and where it came from? > > > yes it s OpenSparc > > > I tried with ISE but only got portability error, so you possible need > > synplify if targetting Xilinx > > > the piece of hardware pictured is ir-relavant, it is I think what the > > authors think a picture of something that is understood as hardware > > Any idea at what FPGA class this design is targeted? Anything available > PQ208 package? > > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Hi Uwe, as ISE crashed so far I dotn have any reports, but from my thumb guess I would say you need at least as much as for LEON3 or more. LEON3 can be fit to S3-400, but for real work s3-1000 or larger is recommended so the same applieas to srisc as well. meaning there are no suitable Xilinx FPGAs in non-BGA to answer your question. I think biggest non-BGA packaged RAM FPGA would be some Cyclone in PQ240 and biggest non-BGA if non volatile are counted is Actel, I think they offer all FPGA also the largest in PQ208. It would be nice of course if Lattice XP2 would have large non-BGA devices, but that info want be available until Q4 AnttiArticle: 108782
I am looking at using the XPLA3 in a new design and am having trouble finding an evaluation board. So I started looking around and see that Xilinx seems to be severely curtailing support of these parts. There Xilinx no longer offers evaluation boards and I can't find many third party boards that are still offered. On the bright side, when I did a search at Nuhorizons for XCR3128, I got lots of hits. That alone would not give me confidence, but not only did I get the XCR3128XL that I need to use, I found the XCR3128 without the XL which is an even older part. If they are still selling those parts, I guess I can expect to see the XCR3128XL around for quite a while. The Coolrunner II may be a bit lower power, but the XPLA3 parts are nearly as low power for our application and only require a single power voltage. That makes them *more* power efficient. I just wish Xilinx provided as much support for the XPLA3 parts as they do for the Coolrunner II. Are there any advantages of the Coolrunner II parts that I am missing? I see they have input hysteresis, but otherwise they seem pretty much the same as the Coolrunner XPLA3.Article: 108783
Patrick Dubois wrote: > Hello, > > As any user of Xilinx Chipscope Pro probably already noticed, the GUI > is not that great. Especially when it comes to handling buses. One has > to manually group each buses by hand and this is time consuming, > especially if you're like me and you have 3 FPGAs in the jtag chain, > each with 20 different buses. > > So I created a small perl script to automate this process, it's called > csptool. I'm releasing this small script as open-source on Google Code: > http://code.google.com/p/csptool/ > > Here is the help from the script: > -------------------------------------------------------------- > Features: > - Supports multiple FPGA devices and multiple ILA units per FPGA > - Supports Chipscope Pro v7.1.04i and v8.1.03i (Windows). Should > work with other OS and/or other Chipscope versions too. > - Supports regular buses, i.e. bus<0>, bus<1>, but also "state machine > style" buses such > as State_Fdd1, StateFdd2, etc. > > Usage: > - Create a new cpj projet with Chipscope Pro Analyzer (might not work > if project is not "fresh"). > - Import the .cdc files to get relevant signal names. > - For each unit and each FPGA, make the waveform appear by clicking > "Waveform" in the > left project tree. > - Save the project (you don't need to close Chipscope). > - Run the tool like this: csptool your_project.cpj (I suggest to > associate > .cpj files to csptool.exe, so that you can just double-click a .cpj > file) > - Reload your Chipscope projet. > -------------------------------------------------------------- > > To use it, you must install a perl interpreter such as the free > ActivePerl. Once this is done and you know that perl.exe is in your > path, juste type: > perl csptool.pl your_project.cpj > > You can make it even easier by compiling the perl script into a .exe > and associating .cpj files to that .exe. That way, you simply have to > double-click on your project in windows explorer and voilà. I'm sorry > that I can't release a .exe publicly, I don't have a license for a perl > compiler. > > If you want to contribute some features to the script (check the > comments in the script for a suggested todo list) feel free to send me > an e-mail and I'll gladly give you commit rights. > > I hope it can be useful to someone. > > > Patrick Dubois > nice work thanks ...Article: 108784
zwsdotcom@gmail.com wrote: > > Symon wrote: >> <http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/57ca33af15b3aebe/4d135a665d33c860?lnk=st&q=xilinx+group%3Acomp.arch.fpga+author%3Abrian+author%3Adavis&rnum=14&hl=en#4d135a665d33c860> > > > Yes, I should have mentioned that I already tried this - it doesn't > work. Download is completely broken. > > I even tried it on a Macintosh to see if Safari would behave any > differently. I think what they want is IE6 set to safe zone and accept all cookies. "It works when we test it here!" -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens.  --SchillerArticle: 108785
On Sat, 16 Sep 2006 08:43:10 -0700, Austin Lesea <austin@xilinx.com> wrote: >Jim, > >The problem is perhaps a bit more complex than you are suggesting. > >We have customers that require the parts to configure very fast, >basically at the maximum CCLK rate in the data sheet. That said, those >clocks require SI engineering. > >Since some folks require high speed, and others do not, what compromise >can we make? > >Do we put the circuits in the chip and slow the edges down, schmidt >trigger with extreme hysterisis, and just wqalk away from another set of >customers? A ns or two of lowpass-type delay and a half of a volt of hysterisis or so wouldn't slow anybody down. The max S3 CCLK rate is spec'd at 80 MHz, and limited to 20-25 MHz under other conditions. Something that behaves like a TinyLogic schmitt would make everybody happy. I'm now using them adjacent to the CCLK pins. > >I am apalled that people who call themselves 'engineers' (not referring >to you, of course) would completely ignore physics, and continue to act >as if there is no such thing as signal integrity, and continue to waste >their company's money by not doing something that they should be doing >(not just for CCLK, but all the other IO pins on the package, too). The waste of money and PCB real estate is in having to buffer, fan out, terminate, and crosstalk-harden a signal as if it were a system clock, when all that is (or should be) absolutely unnecessary. All pins do *not* need the same signal integrity analysis or treatment, and it would be impossible to provide it in many common situations. Data busses are a common example where hundreds of millivolts of crosstalk may just not matter, so we can bunch all those traces together on one layer. I'm appalled that you have such contempt for real concerns of real customers, and insult us to boot. I design with 12 GHz CML when I have to, 35 ps edges with 400 mV swing, but I don't see why Xilinx won't do something simple to make their parts configuration easier and more reliable. JohnArticle: 108786
Regarding the Fairchild Symbol IIr computer, and other obsolete architectures, I suggest reading the old book (out of print) by: Dan Siewiorek, G. Bell, A. Newell, "Computer Structures: Principles and Examples", printed in 1982 by McGraw Hill. --- I've written a couple of notes, in the past about the Symbol memory management that implemented variable length strings in hardware, with primitive memory operations: Assign Group, Store and Assign, Fetch and Follow. --- We also had a hardware implemented multi-tasking job control, hardware source code translator (to polish), and variable length decimal arithemetic. ( I designed the arithmetic and string processors, that processed the data stream High to Low. Also, I've documented that...as it's novel but insignificant today.) -- I also recommend the more modern book by: Mark Hill, Norman Jouppi, and G. Sohi, "Readings in Computer Architecture". (I don't think Fairchild's Symbol is mentioned.) thx. stan mazorArticle: 108787
nico@puntnl.niks (Nico Coesel) wrote: >Hello everybody, > >In a design I'm working on I want to multiply two 16 bit 2's >complement (signed) numbers using the mult18x18 multipliers. According >to the Sparten 3 userguide, it is enough to use the lower bits and >take the result from the output. However, when I do this, the result >is not correct when negative numbers are multiplied, positive numbers >are no problem. > >If I use the highest (MSB) bits of the multiplier, the results are >correct. But... using the highest bits of the multiplier causes my >design to fail timing constraints because the multipliers get slower >when more bits are being used. > Thanks for the responses. Extending the sign makes timing even worse so I guess I'm stuck with using the top bits of the multiplier. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 108788
John, I apologize, I had no intent to insult you. I will pass along your suggestion to the folks who do that design for the config circuits, but I suspect I will hear what I have before ... "it isn't that simple..." As for contempt, I have no contempt for anyone. I just point out that folks save pennies, and then spend thousands of dollars. A company that goes out of business is not a good customer to have. I prefer customers that are making a good profit. AustinArticle: 108789
> > The Coolrunner II may be a bit lower power, but the XPLA3 parts are > nearly as low power for our application and only require a single power > voltage. That makes them *more* power efficient. I just wish Xilinx > provided as much support for the XPLA3 parts as they do for the > Coolrunner II. > > Are there any advantages of the Coolrunner II parts that I am missing? > I see they have input hysteresis, but otherwise they seem pretty much > the same as the Coolrunner XPLA3. > CoolrunnerII: - has FF's which can toggle on both clock edges. So you can e.g. divide easily by 1.5. - optional schmitt trigger inputs - optional bus hold or pullup or floating inputs - has an internal clock divider (/2../16) mode on >=128mc's. - has slightly more product terms than CR XPLA3 - several I/O banks, cpld can be used as level shifter - has more I/O standards than CR XPLA3 on >=128mc's - data gate for more power save control - new design can be flashed via jtag, but operation of old design is still running till next POR - cheaper and faster than CR XPLA3 CoolrunnerII disadvantages: - no 5V tolerant inputs - dedicated JTAG port, can not be used for user data transfer through jtag cable (as CR XPLA3 can) all Xilinx CPLD's do not have input diodes to VCC, makes them useful for hot pluggin. Serial resistors for e.g. 5V input tolerance need an extra diode to vcc, e.g. bar43S or bat54S. MIKE -- www.oho-elektronik.de OHO-Elektronik Michael Randelzhofer FPGA und CPLD Mini Module Klein aber oho !Article: 108790
M.Randelzhofer wrote: > > > > The Coolrunner II may be a bit lower power, but the XPLA3 parts are > > nearly as low power for our application and only require a single power > > voltage. That makes them *more* power efficient. I just wish Xilinx > > provided as much support for the XPLA3 parts as they do for the > > Coolrunner II. > > > > Are there any advantages of the Coolrunner II parts that I am missing? > > I see they have input hysteresis, but otherwise they seem pretty much > > the same as the Coolrunner XPLA3. > > > > CoolrunnerII: > - has FF's which can toggle on both clock edges. So you can e.g. divide > easily by 1.5. > - optional schmitt trigger inputs > - optional bus hold or pullup or floating inputs > - has an internal clock divider (/2../16) mode on >=128mc's. > - has slightly more product terms than CR XPLA3 > - several I/O banks, cpld can be used as level shifter > - has more I/O standards than CR XPLA3 on >=128mc's > - data gate for more power save control > - new design can be flashed via jtag, but operation of old design is still > running till next POR > - cheaper and faster than CR XPLA3 > > CoolrunnerII disadvantages: > - no 5V tolerant inputs > - dedicated JTAG port, can not be used for user data transfer through jtag > cable (as CR XPLA3 can) > > all Xilinx CPLD's do not have input diodes to VCC, makes them useful for hot > pluggin. > Serial resistors for e.g. 5V input tolerance need an extra diode to vcc, > e.g. bar43S or bat54S. You really know the CPLDs. I have not used them in a while and I had forgotten a lot of this. One feature of the XPLA3 may make the selection for me. We have a requirement to be able to reprogram all of the reprogrammable devcies in the system without disassembling the unit. The board this chip will go on will only have SPI connecting it from the main general purpose processors (GPP). I can use the JTAG signals as the SPI port when in user mode. If I add one signal to the interface to switch the XPLA3 pins back to JTAG mode, it will then be fully reprogrammable over the same signals as the SPI port. I will have to make sure that the GPP can bit bang these IO pins, but it would save me having to add an MCU to the board just to reprogram the CPLD! The other candidate for this socket is the Lattice ispMACH4128 part. So far I have not gotten great support. But I can't complain, they did provide me with a full copy of ispLever. I need to check to make sure their parts can be reprogrammed without adding a whole JTAG port to the interface.Article: 108791
Austin Lesea wrote: > Jim, > > The problem is perhaps a bit more complex than you are suggesting. > > We have customers that require the parts to configure very fast, > basically at the maximum CCLK rate in the data sheet. That said, those > clocks require SI engineering. > > Since some folks require high speed, and others do not, what compromise > can we make? > > Do we put the circuits in the chip and slow the edges down, schmidt > trigger with extreme hysterisis, and just wqalk away from another set of > customers? That doesn't work. Can we program the CCLK pin's behavior? > No, because this is a "chicken and egg" problem (have not read in the > bitstream, yet. If you have a solution, I am listening. > > So, rather that characterize my response as callous, unforgiving, and > elitist (which some have seemed to do), it should be seen as "these are > the simple facts." Sorry Austin, but others seem to be able to DO this, so they are not simple facts. Show this datasheet to your design team, next time they try and fob you off with a "it isn't that simple..." http://www.standardics.nxp.com/products/aup/pdf/74aup1g175.pdf This specs 190Mhz min clock, 300Mhz typ. More of this Tinylogic is deploying Schmitt as default, and clearly they have decided the speed impact is tolerable, ( or perhaps their designer's are smarter ? ) Also mention that Atmel spec a 1.5ns (MAX) adder for their Hyst option, on a slower process than Xilinx uses. Hysteresis and speed are NOT mutually exclusive, especially on an ~80MHz CCLK line, that WILL be driven much slower (and with slower edges) in many designs : it is bad engineering to NOT deploy it. You now have customers adding 'band-aid' solutions around your devices because of this, and seem more motivated to fielding excuses than driving a fix. -jgArticle: 108792
rickman wrote: > I am looking at using the XPLA3 in a new design and am having trouble > finding an evaluation board. So I started looking around and see that > Xilinx seems to be severely curtailing support of these parts. There > Xilinx no longer offers evaluation boards and I can't find many third > party boards that are still offered. > > On the bright side, when I did a search at Nuhorizons for XCR3128, I > got lots of hits. That alone would not give me confidence, but not > only did I get the XCR3128XL that I need to use, I found the XCR3128 > without the XL which is an even older part. If they are still selling > those parts, I guess I can expect to see the XCR3128XL around for quite > a while. > > The Coolrunner II may be a bit lower power, but the XPLA3 parts are > nearly as low power for our application and only require a single power > voltage. That makes them *more* power efficient. I just wish Xilinx > provided as much support for the XPLA3 parts as they do for the > Coolrunner II. > > Are there any advantages of the Coolrunner II parts that I am missing? > I see they have input hysteresis, but otherwise they seem pretty much > the same as the Coolrunner XPLA3. What are the relative prices ? I find that is a good indication of EOL, when they start putting "don't bother us prices on the older parts" :) -jgArticle: 108793
Austin Lesea wrote: > Jim, > > The problem is perhaps a bit more complex than you are suggesting. > > We have customers that require the parts to configure very fast, > basically at the maximum CCLK rate in the data sheet. That said, those > clocks require SI engineering. > > Since some folks require high speed, and others do not, what compromise > can we make? > > Do we put the circuits in the chip and slow the edges down, schmidt > trigger with extreme hysterisis, and just wqalk away from another set of > customers? That doesn't work. Can we program the CCLK pin's behavior? > No, because this is a "chicken and egg" problem (have not read in the > bitstream, yet. If you have a solution, I am listening. Of course there is a solution. You can set the default behavior to the slow, safe interface. Then a few clock cycles into the bit stream a bit flips the interface to allow the higher speed, "watch out for yourself" inteface. I seem to recall that other Xilinx parts had something like this in the bit stream. It was likely way back in the XC4000 days, so maybe Peter would remember. > So, rather that characterize my response as callous, unforgiving, and > elitist (which some have seemed to do), it should be seen as "these are > the simple facts." > > It is a high speed interface (because people do use it there), so if you > use it at very low clock rates, you will still need to do the necessary > singal integrity engineering. > > And, if you do not have a tool to do it, our hotline will do it for you, > for free. (I have said this many times before). We will also suggest > you invest in an SI tool (my favorite is Mentor's Hyperlynx), which will > pay for itself when you do not have a pcb respin, once, due to better SI > engineering. > > I am apalled that people who call themselves 'engineers' (not referring > to you, of course) would completely ignore physics, and continue to act > as if there is no such thing as signal integrity, and continue to waste > their company's money by not doing something that they should be doing > (not just for CCLK, but all the other IO pins on the package, too). Yes, this is the sort of response I would expect from you Austin, the know-all, be-all reply that shows you know exactly what is wrong with every other engineer in the world. SI needs to be addressed, but that does not require the expenditure of a multi thousand dollar tool that won't produce didly unless you know exactly how to get the right data into it and that include data the designer has no control over. Just relax a bit and consider that not every design requires a simulation tool to assure that SI is handled properly and the board won't blow up. The idea of adding some safety circuitry to deal with a little noise on the CCLK line is not a terrible thing. Perhaps you could take this back to the chip designers rather than complain about the 'engineers' who buy your parts. To the engineer who wants to solve the problem of using an imperfect transmission line for the CCLK, you might try considering that you can solve the SI issues without treating the signal as a high speed clock. The SI issue is created when the length of the signal line is long compared to the rise time of the driver on the line. You can use the high falutin' termination techniques that will prevent reflections and such from messing up your signals, or you can use a driver with a slow edge rate so that the reflections don't create extra transitions in your CCLK line. It may seem like a "silly" thing to do, but I am surprised that the FPGA is the only part that responds poorly to non-monotonic edges or ringing on the configuration clock line. I have not tried to design in a slow driver, but even if you can't find a small IC that will do the job, I can draw up an emitter follower transistor circuit with an RC that should give you complete control over the edge rate. The dual NPN/PNP comes in a package as small as 1.6 mm sq. which is about like an 0606 resistor. So the total circuit size is the same as using four 0603 components.Article: 108794
Does anyone know of any reviews of different tools, or have any experiance with any of the 3rd party tools, good or bad? For work, I'm looking into what we need, and what our options are. Right now we just have the basic Altera Quartus II and Nios II tools, and we ordered the full version of Quartus II with Alteras stripped down version of ModelSim. I'm the only guy with a lot of FPGA experiance, so at least on that side I can drive our selection process, other then budget issues (still unknown). Other then meeting our basic needs, and our budget, what are things I need to take into account? Except for me, training/learning the tool is going to be the same for the rest of the group, but if I used HDL Designer/ModelSim a lot in school, is that a good reason to just gor for buying them at work (as long as it dosen't break the bank)?Article: 108795
Jim, We also have customers who know SI, and perhaps end up with a resistor for proper termintion. But I will mention it. Thank you, AustinArticle: 108796
Rick,
OK. I never complained about the engineers who use our parts. I
pointed out that there are those who just don't seem to be doing their
jobs (IMHO).
And I do not know everything. In fact, I have already posted that I
know very little: I poll others here at Xilinx prior to my responses.
I am flattered that you thought I actually come up with all of this all
on my own!
And, I do suggest that a little SI goes a long way. When was the last
time you tried HyperLynx? With the little I know, even I can use it easily.
Anyway, thanks for reminding me of the dual speed modes. I recall a
terrible customer issue that involves the dual speed use, where the low
speed worked fine, and the high speed did not. Why? No SI engineering.
So they built it in slow mode, and then changed to fast bitstreams for
production.
Results: line down, and plane flights for all the designers ("How could
you do something so stupid!"). Maybe one disaster is insufficient to
kill a good feature?
OK, I have said I am going back and discuss a more forgiving input with
designers, and I have said SI is a good thing, and saves money.
Please don't put words in my mouth, (or ideas in my head that I never
could possibly have had -- I am just not that smart!)
Austin
rickman wrote:
> Austin Lesea wrote:
>
>>Jim,
>>
>>The problem is perhaps a bit more complex than you are suggesting.
>>
>>We have customers that require the parts to configure very fast,
>>basically at the maximum CCLK rate in the data sheet. That said, those
>>clocks require SI engineering.
>>
>>Since some folks require high speed, and others do not, what compromise
>>can we make?
>>
>>Do we put the circuits in the chip and slow the edges down, schmidt
>>trigger with extreme hysterisis, and just wqalk away from another set of
>>customers? That doesn't work. Can we program the CCLK pin's behavior?
>> No, because this is a "chicken and egg" problem (have not read in the
>>bitstream, yet. If you have a solution, I am listening.
>
>
> Of course there is a solution. You can set the default behavior to the
> slow, safe interface. Then a few clock cycles into the bit stream a
> bit flips the interface to allow the higher speed, "watch out for
> yourself" inteface. I seem to recall that other Xilinx parts had
> something like this in the bit stream. It was likely way back in the
> XC4000 days, so maybe Peter would remember.
>
>
>
>>So, rather that characterize my response as callous, unforgiving, and
>>elitist (which some have seemed to do), it should be seen as "these are
>>the simple facts."
>>
>>It is a high speed interface (because people do use it there), so if you
>>use it at very low clock rates, you will still need to do the necessary
>>singal integrity engineering.
>>
>>And, if you do not have a tool to do it, our hotline will do it for you,
>>for free. (I have said this many times before). We will also suggest
>>you invest in an SI tool (my favorite is Mentor's Hyperlynx), which will
>>pay for itself when you do not have a pcb respin, once, due to better SI
>>engineering.
>>
>>I am apalled that people who call themselves 'engineers' (not referring
>>to you, of course) would completely ignore physics, and continue to act
>>as if there is no such thing as signal integrity, and continue to waste
>>their company's money by not doing something that they should be doing
>>(not just for CCLK, but all the other IO pins on the package, too).
>
>
> Yes, this is the sort of response I would expect from you Austin, the
> know-all, be-all reply that shows you know exactly what is wrong with
> every other engineer in the world. SI needs to be addressed, but that
> does not require the expenditure of a multi thousand dollar tool that
> won't produce didly unless you know exactly how to get the right data
> into it and that include data the designer has no control over.
>
> Just relax a bit and consider that not every design requires a
> simulation tool to assure that SI is handled properly and the board
> won't blow up. The idea of adding some safety circuitry to deal with a
> little noise on the CCLK line is not a terrible thing. Perhaps you
> could take this back to the chip designers rather than complain about
> the 'engineers' who buy your parts.
>
> To the engineer who wants to solve the problem of using an imperfect
> transmission line for the CCLK, you might try considering that you can
> solve the SI issues without treating the signal as a high speed clock.
> The SI issue is created when the length of the signal line is long
> compared to the rise time of the driver on the line. You can use the
> high falutin' termination techniques that will prevent reflections and
> such from messing up your signals, or you can use a driver with a slow
> edge rate so that the reflections don't create extra transitions in
> your CCLK line. It may seem like a "silly" thing to do, but I am
> surprised that the FPGA is the only part that responds poorly to
> non-monotonic edges or ringing on the configuration clock line.
>
> I have not tried to design in a slow driver, but even if you can't find
> a small IC that will do the job, I can draw up an emitter follower
> transistor circuit with an RC that should give you complete control
> over the edge rate. The dual NPN/PNP comes in a package as small as
> 1.6 mm sq. which is about like an 0606 resistor. So the total circuit
> size is the same as using four 0603 components.
>
Article: 108797On 16 Sep 2006 15:39:17 -0700, "rickman" <gnuarm@gmail.com> wrote: >I have not tried to design in a slow driver, but even if you can't find >a small IC that will do the job, I can draw up an emitter follower >transistor circuit with an RC that should give you complete control >over the edge rate. The dual NPN/PNP comes in a package as small as >1.6 mm sq. which is about like an 0606 resistor. So the total circuit >size is the same as using four 0603 components. Good grief, I *know* how to do stuff like this. I just don't like being forced to. JohnArticle: 108798
Austin Lesea wrote: > Jim, > > We also have customers who know SI, and perhaps end up with a resistor > for proper termintion. > > But I will mention it. And remember to point out, that all the SI engineering in the world, and termination resistors, will not solve the problem of slow edges : sometimes the devices that drive the CCLK might be a uC and it might have deliberately slowed edges for EMC reasons (more common these days..) That is why you need a Schmitt! -jgArticle: 108799
Austin Lesea wrote:
> Rick,
>
> OK. I never complained about the engineers who use our parts. I
> pointed out that there are those who just don't seem to be doing their
> jobs (IMHO).
"I am apalled that people who call themselves 'engineers' (not
referring
to you, of course) would completely ignore physics, and continue to act
as if there is no such thing as signal integrity, and continue to waste
their company's money by not doing something that they should be doing
(not just for CCLK, but all the other IO pins on the package, too)."
I would say that claiming to be "apalled" about engineers who use your
parts is "complaining". If not, what *do* you call it?
> And I do not know everything. In fact, I have already posted that I
> know very little: I poll others here at Xilinx prior to my responses.
> I am flattered that you thought I actually come up with all of this all
> on my own!
I think I have a good handle on what you do and don't know. It is the
way you present it that "impresses" me.
> And, I do suggest that a little SI goes a long way. When was the last
> time you tried HyperLynx? With the little I know, even I can use it easily.
I used it on my last board. I find that it is *not* easy to use
because it depends on having good info and I have little reason to
believe many of the device models I have to work with. This was
discussed in a recent class I took and many of the participants and the
instructor all agreed that many BSDL files contain errors.
> Anyway, thanks for reminding me of the dual speed modes. I recall a
> terrible customer issue that involves the dual speed use, where the low
> speed worked fine, and the high speed did not. Why? No SI engineering.
> So they built it in slow mode, and then changed to fast bitstreams for
> production.
>
> Results: line down, and plane flights for all the designers ("How could
> you do something so stupid!"). Maybe one disaster is insufficient to
> kill a good feature?
If your customer does not understand the implications of using the high
speed, why did they attempt it and why, oh why would Xilinx then feel
it was a bad feature??? It almost sounds like you are trying to
protect your customers from themselves by removing useful features.
> OK, I have said I am going back and discuss a more forgiving input with
> designers, and I have said SI is a good thing, and saves money.
>
> Please don't put words in my mouth, (or ideas in my head that I never
> could possibly have had -- I am just not that smart!)
I could never put words in your mouth. I don't think there is any more
bandwidth left... ;^)
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