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
Test Привет олл!Article: 7326
Michael David Scott wrote: > > Michael David Scott (qwerty@WPI.EDU) wrote: > e: I have compiled a file in synopsys (.vhd) and saved it as a .edf file. > : I pulled this into Maxplus II and compiled the logic into a .vho file > : for the component I want to use. Now, I want to use this .vho file to > : perform simulations in Mentor Graphics qhsim with all the timing info the > : file contains. > : > : Problem is, when I create the .vho file- all bus names are changed from the > : format bus_name(x DOWNTO y) to bus_name_1_a, bus_name_2_a....... > : This makes life a bit complicated when attempting to run my test bench. > : It is possible to instatiate a new file on top of my original .vhd code > : (ex. bus_1_a => bus(1) ......) > : :but I'd perfer something like click the button in this window > : to keep original names. > : > : > : Thanks, > : Mike Scott > : > : PS- In addition to a usenet response, an email would be greatly appreciated. > : > : I have found no way around this. You need to create a "wrapper file". I use leonardo - it has a capability of creating a wrapper. It appears that leonardo is the one responsible for breaking apart the busses. -- Remove [no-spam] for email replies.Article: 7327
mmoller@mmoller.mikom.csir.co.za (Michael Moller) writes: >>In the short, no. >[excuses snipped] They may be excuses, but if we can't see a big enough of a market to make money on... Engineers (usually) don't work for free... As I indicated in my previous post however, we are moving to fully portable code. However any 10+ year old company tends to end up having quite a bit of legacy code and we have many other things that our currently paying customers say they want now. (In this industry a company *must* take care of it's paying customers.) >Has anyone ever tried to take a poll of the number of VHDL developers >craving for Linux development tools? Perhaps now would be a good time >to start. VHDL development tools are the single reason I still have >windows on the machine. I currently use Altera's stuff, but would >switch in the blink of an eye if even a half decent set of tools are >made available for Linux. Altera supports a half-dozen unix's already >but seems to be blind to the growing number Linux users. This seems >to be something they share with everybody in the field. >Any ideas on enlightening developers welcome. >If I'm merely delusional and there really are very few Linux-using >VHDL developers out there, feel free to enlighten me! We would also like to know how many engineers would be willing to purchase tools that run under Linix. (Not would like to use, but actually willing to spend the money for.) (I'm just any engineer here, but many of us would like to port to Linix, and managment would likely go for it if they knew that there was big enough of a market.) Todd Walk walk@mrcnext.cso.uiuc.edu toddw@minc.comArticle: 7328
Ive been working with the old Xilinx XC2064 LCA's for a while, using the PC to download bitstreams to the LCA in Master Serial mode. What I'm trying to do now however is to daisy-chain a second LCA in Slave Serial mode. Although the hardware seems quite straight forward I haven't been able to daisy-chain the bitstream file for download in a serial format... Has anybody out there come across this problem (and hopefully solved it) ? I would be grateful if anybody with any suggestions could drop me a mail.Article: 7329
Michael Moller (mmoller@mmoller.mikom.csir.co.za) wrote: : Has anyone ever tried to take a poll of the number of VHDL developers : craving for Linux development tools? Perhaps now would be a good time : to start. VHDL development tools are the single reason I still have : windows on the machine. I currently use Altera's stuff, but would : switch in the blink of an eye if even a half decent set of tools are : made available for Linux. Altera supports a half-dozen unix's already : but seems to be blind to the growing number Linux users. The same with me. Except I use Xilinx. : This seems : to be something they share with everybody in the field. : Any ideas on enlightening developers welcome. : If I'm merely delusional and there really are very few Linux-using : VHDL developers out there, feel free to enlighten me! You are not delusional. The problem is the EDA vendors expect you to pay big bucks for the product if it runs in Unix. They are used to the idea that Unix is for workstations and it is a totally different market. Besides, they hope that all the NT stuff eventually will cost as much as Unix-based SW. I am not sure that companies that make cheaper soft- ware (e.g. Minc) will ever bother to port their VHDL to Linux.Article: 7330
So which mode should we use delay or nodelay? I would guess that a card on
a bus should use nodelay (short setup time, more than 0ns hold time), but a
chip on a motherboard should use delay (large setup time, no hold time).
Why would XACT give more conservative numbers for this? What additional
assumptions do the "massaged" numbers make- there should be no variable
routing estimates for global clock to IOB FFs? Is a narrower temperature
window perhaps being assumed?
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 7331
I am currently designing FIFO for ALTERA 10K family. I need independent
PUSH and POP clocks. Does anyone have an idea besides "Cycle Shared" and
"Interleaved Memory" FIFOs ?
Thanks in advance!
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Article: 7332garyk@svpal.svpal.org (George Noten) writes: > You are not delusional. The problem is the EDA vendors expect you to > pay big bucks for the product if it runs in Unix. They are used to the > idea that Unix is for workstations and it is a totally different market. > Besides, they hope that all the NT stuff eventually will cost as much > as Unix-based SW. I am not sure that companies that make cheaper soft- > ware (e.g. Minc) will ever bother to port their VHDL to Linux. After talking with the guy in charge of synthesis (ie, VHDL EASY, etc), and he says (repeating a quote with his permission) "we will have a fully portable synthesis tool in 6-12 months". I don't know if we would actually offer such a tool for Linix, I wouldn't know what price that it would have, or what feature set that it would have. Roughly (very!) guessing however it would likely be our higher end product (with the corresponding higher price tag). (ps. If you would be willing to pay for such a tool, let us know!) Todd Walk walk@mrcnext.cso.uiuc.edu toddw@minc.comArticle: 7333
George Noten wrote: > > Michael Moller (mmoller@mmoller.mikom.csir.co.za) wrote: > > : Has anyone ever tried to take a poll of the number of VHDL developers > : craving for Linux development tools? Perhaps now would be a good time > : to start. There is a mention of this on www.linuxeda.com, but looks like the site is still under construction. > VHDL development tools are the single reason I still have > : windows on the machine. <sarcasm_on> Oh, but you've got be using Micro$oft Office in order to get any work done of course so you MUST have Windows to run that. <\sarcasm_off> > > : Any ideas on enlightening developers welcome. > > : If I'm merely delusional and there really are very few Linux-using > : VHDL developers out there, feel free to enlighten me! Its kind of a catch-22. If there are no VHDL tools out there for Linux then people who do VHDL development won't be doing it on Linux. But, if there were a decent VHDL simulator like Model Tech's V-System and a synthesis tool like this Minc tool, well then Linux becomes a real contender. You need both to be available at the same time though - Exemplar released Leonardo for Linux but they claim that its sales are rather tepid. Not surprising since there is no VHDL simulator for Linux and Leonardo runs about $8K (the $495 price for the Minc tool seems attractive). > > You are not delusional. The problem is the EDA vendors expect you to > pay big bucks for the product if it runs in Unix. They are used to the > idea that Unix is for workstations and it is a totally different market. > Besides, they hope that all the NT stuff eventually will cost as much > as Unix-based SW. I am not sure that companies that make cheaper soft- > ware (e.g. Minc) will ever bother to port their VHDL to Linux. Well, if the commercial guys won't do it... Seems like there are a lot of University projects out there that could be put together perhaps with a GUI frontend (espresso, SIS, etc) for use on Linux and other Unices. Then the only problem is the VHDL frontend - but there is a project called VAUL (VHDL analyzer and utility library at http://www-nt.e-technik.uni-dortmund.de/m_mvo/vaul.html ) that could probably serve the purpose. VAUL is free, including source code, for non-commercial use. VAUL could probalby be used as the basis for a public domain VHDL simulator as well. Anybody out there working on something like this? It could be just the catalyst we need. TimArticle: 7334
Michael Moller (mmoller@mmoller.mikom.csir.co.za) wrote: : Has anyone ever tried to take a poll of the number of VHDL developers : craving for Linux development tools? Perhaps now would be a good time : to start. VHDL development tools are the single reason I still have : windows on the machine. I currently use Altera's stuff, but would : switch in the blink of an eye if even a half decent set of tools are : made available for Linux. Altera supports a half-dozen unix's already : but seems to be blind to the growing number Linux users. This seems : to be something they share with everybody in the field. Exemplar have made their synthesis tools avaliable for Linux, they come as standard on the CD. You need a floating license, or a dongle if you're that way inclinded. It's faster on a Linux PC than my Sparc 20. : Any ideas on enlightening developers welcome. Start buying stuff for Linux, and telling other developers you're not buying their stuff purely because it's not avaliable for Linux. : If I'm merely delusional and there really are very few Linux-using : VHDL developers out there, feel free to enlighten me! I hope I just have :-) -- Al --------------------------------------------------------- I plan to die like my grandfather, peacefully in his sleep. Not in screaming terror, like his passengers.Article: 7335
In article <5u1go2$i5b$1@vixen.cso.uiuc.edu>, Todd Walk <walk@mrcnext.cso.uiuc.edu> wrote: >mmoller@mmoller.mikom.csir.co.za (Michael Moller) writes: >>[excuses snipped] > >They may be excuses, but if we can't see a big enough of a market >to make money on... Engineers (usually) don't work for free... Neither (usually) do I. >As I indicated in my previous post however, we are moving to >fully portable code. However any 10+ year old company tends to >end up having quite a bit of legacy code and we have many other >things that our currently paying customers say they want now. >(In this industry a company *must* take care of it's paying customers.) Sure, that's simply good business practice. That also seems to answer my question in a rather round-about way. The VHSIC field does not exactly have a huge software market. Simply porting your development tools to Linux is not likely to draw any new customers into the field, and the number of customers drawn from competitors may be limited - depending on the range of chips your product supports. Designers are, after all, unlikely to change the silicon they use overnight. All 'customers' currently in the field are most likely 'paying customers' of some or other company. If _none_ of your 'paying customers' are asking for Linux support they are at least content (if not happy) about using your product as it is. However, if you don't ask them you won't know. Engineers (generally) are unlikely to complain about things they can't fix, and the things they can they do (if it bothers them enough). >We would also like to know how many engineers would be willing >to purchase tools that run under Linix. (Not would like to use, >but actually willing to spend the money for.) (I'm just any >engineer here, but many of us would like to port to Linix, and >managment would likely go for it if they knew that there was >big enough of a market.) I'm in much the same situation. I could probably persuade management to purchase one or two packages as well as a support contract - provided it supports the silicon we use. I imagine most engineers would use a Linux port in preference to the others, just like you would like to do the port. The problem is in quantifying and getting this information through to management. You might well be surprised at the market possibilities. These are my perseptions of reality and may or may not have anything in common with reality as perceived by my employer (or anyone else). l8r mikeArticle: 7336
Hello, Does anybody has a schematic of a MACH131 programmer or a datasheet about programming of this AMD component. Thanks in advance, Christian.Article: 7337
To help you, it would be nice to have a few more details, such as 1) how are you doing download in master-serial with a PC? This doesn't match my understanding of master-serial (which works with one of the 17xxx eprom parts. 2) how are you creating the combined bitstream 3) what does the header look like (in your file) 4) what does the header look like going into the first chip 5) what does the header look like coming out of the first chip, 6) how are you generating CCLK 7) how are you controlling done/program 8) what is the downstream chip (is it also a 2064) 9) are you creating you 2064 bitstreams with M1 or M2 software 10) how are you controlling reset etc. Philip Freidin. In article <01bcb2ff$ce0b8f80$eb489f82@cal1.eee.strath.ac.uk> you write: >Ive been working with the old Xilinx XC2064 LCA's for a while, using the PC >to download bitstreams to the LCA in Master Serial mode. > >What I'm trying to do now however is to daisy-chain a second LCA in Slave >Serial mode. Although the hardware seems quite straight forward I haven't >been able to daisy-chain the bitstream file for download in a serial >format... > >Has anybody out there come across this problem (and hopefully solved it) ? > >I would be grateful if anybody with any suggestions could drop me a mail.Article: 7338
Use the DualPort RAMs in the Xilinx XC4000E, EX, or XL products, that are real dual port RAMs. Philip Freidin (for reference, go to the IBM Patent WEB server, and lookup 5631577 :-) In article <872698617.16310@dejanews.com> oivanov@westell.com writes: >I am currently designing FIFO for ALTERA 10K family. I need independent >PUSH and POP clocks. Does anyone have an idea besides "Cycle Shared" and >"Interleaved Memory" FIFOs ? >Thanks in advance! > >-------------------==== Posted via Deja News ====----------------------- > http://www.dejanews.com/ Search, Read, Post to UsenetArticle: 7339
Michael David Scott wrote:
>
> Michael David Scott (qwerty@WPI.EDU) wrote:
> e: I have compiled a file in synopsys (.vhd) and saved it as a .edf file.
> : I pulled this into Maxplus II and compiled the logic into a .vho file
> : for the component I want to use. Now, I want to use this .vho file to
> : perform simulations in Mentor Graphics qhsim with all the timing info the
> : file contains.
> :
> : Problem is, when I create the .vho file- all bus names are changed from the
> : format bus_name(x DOWNTO y) to bus_name_1_a, bus_name_2_a.......
> : This makes life a bit complicated when attempting to run my test bench.
> : It is possible to instatiate a new file on top of my original .vhd code
> : (ex. bus_1_a => bus(1) ......)
> : :but I'd perfer something like click the button in this window
> : to keep original names.
> :
> :
> : Thanks,
> : Mike Scott
> :
> : PS- In addition to a usenet response, an email would be greatly appreciated.
> :
> :
Mike,
We are just started using a VERY similar process/tools here ... What follows is a brief outline:
In Leonardo,
1) load the library for your part
2) load your design (vhdl files probably?) use the flow-guide
3) create the .edf file
**4) create a wrapper (I/O -> Create Wrapper) file for use later
In Maxplus2,
1) import your design
2) compile your design, be sure to setup the actual device, global options, design doctor
stuff etc. The netlist writer settings we use are for Mentor Graphics using edif 2.0
3) the impt files to get at this stage are the .edo and .sdo, we still haven't figured out
how to use the exported .vho file ... (anyone else??)
In Leonardo,
1) load the library for your part
2) read in the altera edf file (Tools -> Conveniance Procedures -> Read Altera)
3) create a structural vhdl file (I/O -> Write File, specifiying VHDL output) which is
based on the post place and routed synthesis stuff.
Edit the newly created vhdl-synthesis file changing the entity/architecture name to something
else so that you know it is the sythesized model, and not your earlier model, you may also
need to replace library references for Vital libs or your part-library.
Compile this file into your library ... cross your fingers that somewhere along the way
something didn't get dropped.
Now go back to the wrapper created seemingly a long time ago, and edit it to create another
architecture of your design, which basically uses the synthesis-model as a component.
You will have to change some name to make the connection (removing underscores and other
annoying things that creeped in).
Compile this file into your library, and now you are finally ready for qhsim (or connecting
to a test-bench model).
The qhsim command line syntax varys depending on your use but you should be able to type
something like "qhsim -sdf[min,typ,max] [the name of the .sdo file generated by MaxplusII",
and it should be smart enough to associate the .sdo timing file with the correct model.
Hope this helps,
Todd Stevens
============================================================================
Todd Stevens Voice: (425) 885-8597
AlliedSignal Aerospace Fax: (425) 885-2994
15001 NE 36th Street Email: todd.stevens@alliedsignal.com (work)
Redmond, WA 98073 stevensta@(no-spam)aol.com (home)
============================================================================
Article: 7340Joseph, > So which mode should we use delay or nodelay? I would guess that a card on > a bus should use nodelay (short setup time, more than 0ns hold time), but a > chip on a motherboard should use delay (large setup time, no hold time). According to the data book, DELAY is the mode you want to use. It supposedly requires 7ns setup and 0ns hold. > Why would XACT give more conservative numbers for this? What additional > assumptions do the "massaged" numbers make- there should be no variable > routing estimates for global clock to IOB FFs? Is a narrower temperature > window perhaps being assumed? I don't know what the exact (no pun intended) numbers are, but they e-mailed me a PERL script called 'model_io' that I had to run on the simulation .xnf file. This script changed the INFF setup and hold values to be 7setup and 0 hold so I could pass simulation.... What the claim was is as follows: "Run the model_io Perl script, (model_io version 2.01 or higher should be used). This corrects known conservative modeling values for the setup/ hold and clock-to-output timing of the I/O flip-flops. The Perl script provides the guaranteed data book values in the final .xnf file (see the XC4000E Technical Data data sheet). The Perl program version 5.00 or higher is required to execute the model_io script," So, no, it is not temperature related, as it shouldn't be. My understanding is that the numbers used in the speed files is 'conservative'....and does not match the data book values. Note the data book 'guaranteed' values require the use of a primary global clock, and it obviously must be direct. Alas, though I have this nice script, all I know now is my design passes a 7ns setup and 0ns hold time simulation....but still doesn't work in the system with the one bridge - 21152-AA. Argh! AustinArticle: 7341
On Thu, 28 Aug 1997 09:44:55 GMT, fliptron@netcom.com (Philip Freidin) wrote: >Use the DualPort RAMs in the Xilinx XC4000E, EX, or XL products, that >are real dual port RAMs. Or you could also use ORCA, which would be preferable from my perspective. :-) StuartArticle: 7342
Stuart Clubb <s_clubb@netcomuk.co.uk> wrote in article <3405958e.13093178@nntp.netcruiser>... > On Thu, 28 Aug 1997 09:44:55 GMT, fliptron@netcom.com (Philip Freidin) > wrote: > > >Use the DualPort RAMs in the Xilinx XC4000E, EX, or XL products, that > >are real dual port RAMs. > > Or you could also use ORCA, which would be preferable from my > perspective. :-) > > Stuart > or you could use actel a3200dx family (some members). i have no perspective. :^)Article: 7343
Michael Moller <mmoller@mmoller.mikom.csir.co.za> wrote in article ,
>
<snip>
> All 'customers' currently in the field are most likely 'paying
> customers' of some or other company. If _none_ of your 'paying
> customers' are asking for Linux support they are at least content (if
> not happy) about using your product as it is. However, if you don't
> ask them you won't know. Engineers (generally) are unlikely to
> complain about things they can't fix, and the things they can they do
> (if it bothers them enough).
i think this is a bit of an overgeneralization of engineers. personally, i
have seen a lot of engineers be masters at complaining! on a more serious
note, i have given lots of critical feedback to companies about things to
fix, features to add, etc. now, some companies just put these requests in
the round file, nothing gets better, so users generally give up on the
company/product. other companies love getting feedback from the field and
incorporate what they hear. and when local fae's show up, they often take
a pretty good beating! the good ones take notes and pass it back to the
factory. on the factory side, at one company i worked at, they would get
their big customers to come in early in a product development cycle to use
the product and provide feedback so the released product reflects not only
in-house factory engineers but users too. now, many of todays design tools
are unfixable by user engineers in the field and the only way to get the
improvements that you want is to 'complain.'
rk
Article: 7344The Intel FLEXlogic iFX8160 Evaluation Board provides a convenient means to examine, load and read the SRAM contents, and program the iFX8160 programmable logic device. The board consists of a 208 pin SQFF socket for the iFX8160, 2 - 16 character LCD displays, two header sockets for connecting to host PC, 200 test points, and A.C. power adapter (115 & 230 volt compatible) Price: $150Article: 7345
Computer Graphics & Design is a compnay which can create for you or your company a web page or any type of JAVA applet which you may desire. We have the lowest rates in the business and yet at the same time have the highest quality of web page creation in the industry. Our web page designers will design your web page to your exact specifications. For more information please email us at either: DrVBaSiC@aol.com or OakRaid99@aol.com Or you may send us a fax at: (516) 327-5054 Or mail us at: Computer Graphics & Design 973 Hempstead Turnpike Franklin Square, NY 11010Article: 7346
These parts are fairly trivial, but I can understand how the demands of VHDL might slow you down. Over here in schematic land where I spend most of my time, the 54xx59x parts would take about 5 minutes each to draw. The '595 is just 8 repetitions of 2 FFs and a tristate buffer. The '597 is just 8 repetitions of a FF and a FF with async load. You've indicated 54xxxxx parts which are military temp range. Most FPGA/CPLD vendors have parts that can easily do what you want. If the Xilinx parts you are targetting are the FPGA's and the '595 is not directly driving pins (with the tristate outputs), you can implement the tristate stuff inside the chip, but unless you intend to have multiple things reading and writing the tristate bus inside the chip, I would probably recomend against using the tristate capability. Far more info is required to say for sure one way or the other. For the FIFO, I would of course recomend the Xilinx XC4000E/EX/XL parts with dual port RAMs, which is the way I do all my FIFOs in FPGAs. I may have mentioned the dual port RAMs in a recent previous post. Philip Freidin In article <5trc50$84j@gcsin3.geccs.gecm.com> david.surphlis@gecm.com writes: >hi there all, > Is there any-one out there who is aware of >xilinx equilvent parts for the following ttl distrete parts for >use in an fpga design .. > shift registers as listed below > 54xx595 > 54xx597 > or fifo 16x4 > >i was considering using vhdl , but the code for these parts >escapes me to date. >if anyone who can help please let me know >thanks davey.Article: 7347
In article <EFL1wz.87r@world.std.com> jhallen@world.std.com (Joseph H Allen) writes: >So which mode should we use delay or nodelay? I would guess that a card on >a bus should use nodelay (short setup time, more than 0ns hold time), but a >chip on a motherboard should use delay (large setup time, no hold time). For rock solid designs, you should use the delay mode (which is the default) since it will work no matter how fast your external stuff gets (assuming a ballanced clock tree at the board level. Of course, 0nS hold leads to larger setup times, and this directly impacts the available nS for cycle time. In some systems, you KNOW that the data can't go away in less than the hold time of the nodelay mode. This could happen with a multiphase clocked system, or where the depth of the logic that is generating the input is so deep that you believe that the hold time will always be met, or there is interconnect transport delay that meets the requirement. With regard to logic delay, remember that manufacturers of logic and FPGA devices make no guarantee that they will not ship faster parts to you in the future, even though they may label them as slow parts, and charge you the lower price. (This is not a joke. This happens all the time) The multiphase clock system is a reasonable candidate for nodelay. Interconnect delay is also a candidate, but in fast systems (which is where you really care about squeezing every nanosecond out of the cycle time and where you might be considering nodelay, to reduce set up time), the interconnect delay is unlikely to be a match for the hold time requirements which can ammount to several nanoseconds. On the otherhand, unless you physically change the interconnect, the delays don't change much except when the speed of light changes. (Sci-Fi story idea: An FTL space ship that works fine at take off and getting to planetary orbit on impulse engines, but when the Warp Engines come on line, the control and computer systems all start failing because of hold time violations! Man-o-man that sounds like a thrilling hard core Sci-Fi story to me.) You could also use nodelay with inputs that are asynchronous, since setup and hold are irrelevant anyway, but then nodelay does nothing to help either. >Why would XACT give more conservative numbers for this? What additional >assumptions do the "massaged" numbers make- there should be no variable >routing estimates for global clock to IOB FFs? Is a narrower temperature >window perhaps being assumed? The reason and explanation for this is complex: 1) The XACT timing model is made up of hundreds of delay pieces, and which are stuck together by the timing analyzer to come up with the reported delays. 2)Because of the way that IC testers work, anything that you measure on an IC tester has to include a guard band to cover uncertainty in the difference between what the tester reports, and what is reality. Typical production IC testers may have as much as 1nS guard band added by the test program author. The really expensive testers ( more than a few million dollars each) might cut this down to 200pS. What IC manufacturers want is to grade devices according to pass/fail, and speed bins. If you read a data sheet, and it tells you that the device has a guaranteed clock to out delay of 8nS, the actual limit that the tester may be set to is 7nS, so that any device that passes the test, will always meet the data sheet guarantee, whether it was a good or bad day for the tester, and regardless of the ammount of moon-wobble that day. The extra nS covers it. Because of the guard banding, all the delay pieces in the Xilinx timing data have their own guard band added to them, when they are tested, and this is reflected in the speed files that drive the timing analyzer that you use. But the reality is that all these guard bands do not actually ship with the chips, they were on the tester to make sure that what the data sheet said for each of the pieces would be true. So Xilinx now does an extra set of 'system path' tests, that measure the complete pin to pin path delay, using global nets and I/O flip flops, which means that there is no 'discretionary routing' involved. You will find these numbers in the data book in the section titled: "Guaranteed Input and Output Parameters (Pin-to-Pin)" and these numbers are also measured on the IC tester, with guard bands. But.... only one guard band per path, rather than the sum of N pieces plus N guard bands. Unfortunately, these end-to-end path times are not part of the timing model that the Xilinx timing analyzer uses. Hard to believe, but there you are. So repeating your question: >Why would XACT give more conservative numbers for this? What additional >assumptions do the "massaged" numbers make- there should be no variable >routing estimates for global clock to IOB FFs? Is a narrower temperature >window perhaps being assumed? The numbers are not so much conservative, as being based on a less than wonderful timing model. There are no additional assumptions for the pin-to-pin timing, just the lack of adding multiple artificial guard bands to the delay being calculated. The numbers given in the data book are for the full temperature and voltage range that the device is specified for. Philip Freidin.Article: 7348
Dear contributors Thanks to Peter Afke, Stuart Chubb, Philip Freidin and others who have enlightened us on the fact that it is now possible to put FIFOs that work into programmable logic. The arguments have convinced me that I would be much better buying portable tools which would work at least with both 4kE and Orca, if not also with the 10k and Actel parts which I'm not sure do quite the job I want. The job is a number of small FIFOs, ideally 10 bits wide but 9 is ok, and mostly 32 bytes deep. There will additionally be one or two wider, at 32 to 40 bits wide, and probably a bit deeper too. One side of the FIFOs runs at 10 to 25 MHz, but occasional sequential accesses are separated by only 40ns, possibly by only 20ns. The other side mostly runs at a similar speed, but one application would be ideal if it ran at 60 to 100 MHz. Of course it is possible to jiggle the design so that the FIFO itself is synchronised with one clock, and there is logic at the other end to sort the asynchrisms out. But I'd much prefer all that to be hidden in the DPRAM clocking, so that I can treat each end as totally independent of the other end. If anyone can tell me about problems in dong this with 4kE, I'd be grateful. If anyone can tell me that any of the other devices really does this cleanly, I'd also be grateful. But even if the 4kE devices are the only ones that do the job now, I still don't want to be saddled with a single manufacturer's tools. At the moment I'm only interested in up to about 50k "gates", but it's always easier to use more. So If I had, say $10k to $15k to spend on CAD tools, including generic, portable schematics or VHDL, plus P&R for a couple of vendors, what should I buy? Paul -- Paul Walker 4Links phone/fax paul@walker.demon.co.uk P O Box 816, Two Mile Ash +44 1908 http://www.walker.demon.co.uk Milton Keynes MK8 8NS, UK 566253Article: 7349
Tim Warland <twarland@NOSPAMnortel.ca> wrote in article <33FAE72B.4487EB71@NOSPAMnortel.ca>... > Exjobbare Joachim Strombergson wrote: > > > > I'm having problems using LogiBLOX components as component instances in > > my VHDL-code. I'm using the LBGUI tool to customize the blocks to match > > my need. I then try to include these block in my code by inserting the > > generated VHI-file into my code and completing the port assignments. But > > This is the problem. DO NOT insert the code into your code. The VHDL > output is really just a simulatable model, NOT a synthesizable model. > You should treat the logiblox as a hierarchical piece of the code and > instantiate the module as a lower hierarchy. > LBGUI output several files; vhi, vhd and ngo. The vhi has the component declaration and instantiation, the vhd file is the simulatable model, and ngo is the xilinx macro. You are correct in adding the vhi file into your source vhdl. You will need to chop it up a little to insert thr declaration and instansiation into the right places tho'. > > when I try to read in the design into Synopsys Design Analyzer the tool > > does not recognize the component. > > Correct, because it is not synthesizeable. You just used LBGUI to > optimize > the block, don't get Synopsys to have its way with it. The NGO output > of the logiblox IS the synthesized code. In your hierarchical design, > you need a synthesis black_box or similar don't touch attribute to get > synopsys to compile the design correctly but not synthesis the LogiBlox > component. > > > > I either would like to inlude the LogiBLOX like any other library, and > > then customize the component with attributes (but don't know how), or > > somehow make Synopsys realize that the implementation of the component > > is given by the generated netlist in the NGO-file. > > > LogiBlox does customize the component and you do include the component > like any other library. I suggest you look in the documentation for > examples of including logiblox components. (I'd give it a shot but > I'm a verilog guy). > To simulate the block you have to complile the vhd file and three xilinx libraries, these you will find in the xilinx directories under logiblox. Include this in your simulation (use work.all) and all shlould be fine. Nick Barton
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