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
We are designing a system using a SmartMedia card. As the system stands today, we would like to use a CPLD, particularly the Xilinx XC95144XL, as the controller. This chip also provides interfaces to several other devices, including an SRAM chip, an FPGA, and a data header (for direct interfacing). I've been working on the controller design, and it's coming along, but the SmartMedia interface, while simple, isn't necessarily fall-off-a-log and the need to interface with the other devices complicates the problem. One of the things I've been looking for is if there is some nice core available for a CPLD or FPGA implementation that will implement the SmartMedia controller functionality so that I can use a pre-debugged design and save time, effort, and possibly chip real estate. My first priority is simplicity of interface. It's critical to note that as the design stands today, there is no microprocessor anywhere within the system. We want something that integrates the core features to interface with the SmartMedia card, stripped of unnecessary bells and whistles. It should operate stand-alone within the CPLD because at system power-up we expect only the flash card and the CPLD to manage the "boot" process. The second priority is system flexibility. I'd prefer a design that makes the minimum of assumptions about what kind of system you're putting it in, what the data interfaces are going to be, what signalling protocols you're going to use, and what other devices are going to be in your system. We have a very unique architecture that's sufficiently different from conventional designs that too many assumptions may badly constrain our design. In this regard, since the CPLD is going to be used for other things, the less space on the chip a core uses, the better, so we can integrate more other logic on it. Is there some core or reference design available for this kind of system? I'd also like to get some input for the next revision of our system in regards to design choices. I opted for a CPLD, without microprocessor or microcontroller, and for SmartMedia flash, because these seemed to offer the best possibilities both for the simplest and the most flexible interface. What are your thoughts on this? Are there any particular devices you'd recommend especially highly? Please don't constrain yourself to the CPLD/Smartmedia implementation. Go ahead and tell me if that kind of structure really does make sense, and what other alternatives there may be. Thanks for any input. Alex Rast arast@inficom.com arast@qwest.netArticle: 32326
> We are designing a system using a SmartMedia card. As the system stands today, > CPLD or FPGA implementation that will implement the SmartMedia controller > functionality so that I can use a pre-debugged design and save time, effort, > and possibly chip real estate. What are you trying to read/write off that SmartMedia card? (In other words, what do you expect this "controller" to do?) Even if you're just using the device as raw flash blocks and not implementing an SSFDC-compliant (i.e. DOS) filesystem on it, there's a lot of work to be done and I think the IP you're looking for is going to be at least as complicated as a simple microcontroller. The electrical interface and timing to perform command and data read/write ops is very simple, but the algorithms to do something useful with the device are pretty darn complicated!! :) For instance, you need to identify the card and establish the block and page sizes. You have to read-erase-write for sub-block-size writes to blocks that already contain data, and that could require as much as 16Kbytes of registers (!!!!!). You have to read the redundant area and perform defect management. That's a lot of complexity. If you plan to implement a compliant card format that can be read by other SSFDC-using devices (such as card readers on PCs!) then you need to perform logical-to-physical mapping and it's not simple. I guess if you were willing to use a totally proprietary card format (that will require special hardware to write) and you were willing to assume that there are no defects on the card, and none will ever develop [or the card becomes useless once it develops a defect], the task could be simple enough to do in hardware, but my gut feeling on this is that it will be more expensive in development time to do this than it would be to add a "real" micro of one kind or another. Unfortunately your posting sort of reads like this: "I want recommendations for a totally customized special-purpose piece of IP that is specific to our very very strange and unorthodox system, but is also so generic that it works in all possible circumstances and can use any signaling system now known or hereafter invented" :) Can you narrow down some of the unknowns for us? In particular: * do you need full SSFDC compliance (meaning a card that can be read/written in PCs)? * do you need read/write or just read? * what is the reason for avoiding a microcontroller? I don't see why adding a microcontroller makes a system automatically "complex" or non-"flexible", any more than an FPGA or CPLD does. Or do you intend to turn this entire thing into an ASIC someday? > The second priority is system flexibility. I'd prefer a design that makes the So restricting yourself to a particular card size is not an option then. Having worked with several of these removable flash media types (see my work URL in sig), I would suggest that it would be easier to use CompactFlash for a "boot" application if you can't use a microcontroller, because the card contains its own microcontroller to do the defect management and other complicated stuff for you. You wouldn't need a lot of "if then else" sort of stuff for a "boot" application (loading FPGA data off card?); you could use LBA mode with incrementing sector addresses. I've never seen anything that used SSFDC media that didn't contain a microcontroller. Even the interface products for other storage systems to SmartMedia contain microcontrollers. The "interface ASICs" you may find mentioned are in fact microcontrollers. FWIW, I have a vaguely similar application of SSFDC (actually NAND flash chips not packaged for removability). For cost reasons and also to make OS design a bit more elegant, we are moving a product from holding its entire OS in bootable NOR flash to having only a tiny bootloader in OTP EPROM (cheap) and a DOS-formatted NAND flash chip (cheap and same pinout for all possible device sizes) holding the OS (plus a backup copy) in addition to some spare space for user files. -- -- Lewin A.R.W. Edwards Personal http://www.larwe.com/ Work http://www.digi-frame.com/ "... a man who is endowed with real qualities of leadership will be tempted to refrain from taking part in political life; because [...] the situation does not call for a man who has a capacity for constructive statesmanship but rather for a man who is capable of bargaining for the favour of the majority. Thus the situation will appeal to small minds and will attract them accordingly."Article: 32327
In article <oVOY6.8598$8P6.2131176@typhoon1.gnilink.net>, "Lewin A.R.W. Edwards" <larwe@larwe.com> wrote: >> We are designing a system using a SmartMedia card. As the system stands >today, >> CPLD or FPGA implementation that will implement the SmartMedia controller >> functionality so that I can use a pre-debugged design and save time, >effort, >> and possibly chip real estate. > >What are you trying to read/write off that SmartMedia card? (In other words, >what do you expect this "controller" to do?) Really just provide an interface whereby other devices can read or write to the chip, without having to know *a priori* the details of the hardware interface and signalling to the Flash. In other words, so that other devices might interface through a bus x bits wide to the CPLD, which can then interface them to the flash through the 8-bit wide data bus plus the control lines. > Even if you're just using the >device as raw flash blocks and not implementing an SSFDC-compliant (i.e. >DOS) filesystem on it From the POV of the CPLD, we can view the device as raw flash blocks. We don't have to implement SSFDC compliance, although we could, but in any case it would be the other device, not the CPLD, which would handle that layer. >, there's a lot of work to be done and I think the IP >you're looking for is going to be at least as complicated as a simple >microcontroller. The electrical interface and timing to perform command and >data read/write ops is very simple, but the algorithms to do something >useful with the device are pretty darn complicated!! :) > >For instance, you need to identify the card and establish the block and page >sizes. I'm open to doing it either way - via the CPLD or coming from the other devices. The CPLD could pass this information back to other devices and let them handle the rest of the details of the transfer from that point, as another option. >You have to read-erase-write for sub-block-size writes to blocks that >already contain data, and that could require as much as 16Kbytes of >registers (!!!!!). I am *definitely* planning on doing this via the other devices attached to the CPLD! > You have to read the redundant area and perform defect >management. As it turns out, the nature of the rest of our system will make the problem of defects, to a large extent, immaterial. We have done calculations that show that as much as 20% of the data can be bad without having any significant effect on performance. Where it did turn out to be an issue, we'd be handling it on other attached devices. .. > >Unfortunately your posting sort of reads like this: "I want recommendations >for a totally customized special-purpose piece of IP that is specific to our >very very strange and unorthodox system, but is also so generic that it >works in all possible circumstances and can use any signaling system now >known or hereafter invented" :) I agree that my posts have a tendency to sound that way. I like to state things in general terms first so as minimize the degree people answer coming in with preconceptions or worse still, imagining that our design is set in stone, and that *we* have a lot of preconceptions we're not willing to alter. If I were to reword what you've stated above to reflect (if humorously) what I was really trying to convey, it would be: "I want recommendations for a piece of IP that is so generic that it works in all possible circumstances and can use any signaling system now known or hereafter invented, including our very very strange and unorthodox system." >Can you narrow down some of the unknowns for >us? In particular: > >* do you need full SSFDC compliance (meaning a card that can be read/written >in PCs)? No. It's a nice-to-have. >* do you need read/write or just read? Read-write. (If that were not the case, why not just use PROM?) >* what is the reason for avoiding a microcontroller? Redundant parts, extra programming, serial execution, slower speed, added cost, and it might isolate the other devices from the memory subsystem. > I don't see why adding >a microcontroller makes a system automatically "complex" or non-"flexible", >any more than an FPGA or CPLD does. We're already going to need one of those devices anyway. Adding a microcontroller will thus definitely mean adding a part, interfacing, etc. What I mean by "flexible" is, an FPGA/CPLD not only can be anything you want, but it can suddenly become something else, if that's what you need. A microcontroller has a definite instruction set and hardware layout, which means at least from a certain standpoint that the data lines, electrical interfacing, and communications protocols are going to be fixed. That's *my* initial thinking, anyway. But again, I'm not in any way opposed to using a microcontroller, if it's going to be able to be made as simple and flexible. Can you outline where the compelling benefits to a microcontroller might be? > Or do you intend to turn this entire >thing into an ASIC someday? Long-term, probably yes. I don't see uC's being a big issue here, however, as plenty of uC producers offer versions available as ASIC cores (which they may themselves very well have integrated in an ASIC they sell) So we could use a uC without fear that it might hamper integrating our design onto an ASIC later. >> The second priority is system flexibility.... >So restricting yourself to a particular card size is not an option then. No. > >Having worked with several of these removable flash media types (see my work >URL in sig), I would suggest that it would be easier to use CompactFlash for >a "boot" application... But doesn't the CompactFlash spec, in emulating a hard drive, impose requirements on data formatting, communications protocols, etc? In other words, does that not then require that you have a PROM and a rather rigidly defined data interface? (lots of interface lines, with specific requirements for each line). If my impression is correct, then your system will in some ways have to resemble a typical PC. Correct me if I'm wrong. Alex Rast arast@inficom.com arast@qwest.netArticle: 32328
The unisim source should be in your xilinx install directory under $XILINX/vhdl/src/unisims. You'll need to compile the library for your simulator. There are instructions available in the answers database on the xilinx website. If you can't find them there, I'm pretty sure you can download them from xilinx's website, but I'm not sure exactly where they are. If you can't find them there, Aldec has them on their website under the downloads, although you should probably check the version, it may not be the latest. Charles Ross wrote: > Im sure this is probably the most basic of questions, but: > > Im interested in using the unisim library withour Virtex and VirtexE > parts. > From what I understand, I need a vhdl file with the behavioral > description of each of the macros (for simulation) which I then disable > using pragmas in synplify. The black boxes then get caried down to the > foundation tools, and get mapped at that time. -- Let me know if Im > off base here, > > Anyway, the question is: Where do I get the vhdl file(s) which contain > the library? I could not find them on the foundation CD, nor in my > synplify install (I wasnt expecting them in synplify but just for > completeness... ) Do I need to use coregen to make them? How is that > done? I seem to be snagged here. > > Thanks! > > -- > _____ _____ > ___ | | __ | > |___| | --| -| > |_____|__|__| -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 32329
>"Dave Feustel" <dfeustel@mindspring.com> wrote in message >news:9ec4nt$ipc$1@slb6.atl.mindspring.net... >> I'm looking for taps for 64-bit linear feedback shift registers. >> Can someone post either values for such taps or a source >> of information for generating the taps? If you want the longest period, then you want what is called a primitive polynomial modulo 2. There are a number of descriptions, the one I have is in "Numerical Recipes in C". (64,4,3,1,0). Depending on which way you put the logic together (there are symmetry operations), that is taps 0, 1, 3, 4. -- glenArticle: 32330
> Really just provide an interface whereby other devices can read or write to > the chip, without having to know *a priori* the details of the hardware > interface and signalling to the Flash. In other words, so that other devices So if I read this correctly, you are trying to create an abstraction layer, with the goal that at some future time you might replace the SSFDC-based system with some other removable storage. > From the POV of the CPLD, we can view the device as raw flash blocks. We don't > have to implement SSFDC compliance, although we could, but in any case it > would be the other device, not the CPLD, which would handle that layer. > [...] > I'm open to doing it either way - via the CPLD or coming from the other > devices. The CPLD could pass this information back to other devices and let > them handle the rest of the details of the transfer from that point, as > another option. Whoa! On one hand you want to totally abstract the storage layer from the other devices. On the other hand, you are happy to do the logical and physical layer format management in the external device? That work is all highly SSFDC-specific, so your abstraction is destroyed. Or are you only seeking to abstract the signal timing, so that SSFDC can be tied to a variety of different host buses? > >Unfortunately your posting sort of reads like this: "I want recommendations > >for a totally customized special-purpose piece of IP that is specific to our > > I agree that my posts have a tendency to sound that way. I like to state Remember, I was being humorous there, or at the very least wry :) As I'm sure you've noticed, I'm a fairly sarcastic and cynical bastard, it will likely get me shot someday. But I digress: > things in general terms first so as minimize the degree people answer coming > in with preconceptions or worse still, imagining that our design is set in The flip side of that coin is that if you say "I am solving some non-academic problem XYZ", you're a tad more likely to get people responding who have done something directly substitutable for what you want. If you say "We intend to do X, and the problem we've hit is how to do sub-task X sub 5", someone else might say "Well, try doing Y instead". > >* do you need read/write or just read? > > Read-write. (If that were not the case, why not just use PROM?) *shrug* I wasn't sure. Removability and the convenient package, maybe. And you did say it was for a "boot" application of some sort. (SSFDC is available in mask-ROM flavor, too, btw). > >* what is the reason for avoiding a microcontroller? > > Redundant parts, extra programming, serial execution, slower speed, added > cost, and it might isolate the other devices from the memory subsystem. I'm still confused on a couple of points, sorry. 1. "extra programming" - your CPLD/FPGA has to be programmed anyway. So using a microcontroller instead is no loss from that standpoint. The micro could even load the FPGA's configuration RAM if necessary; that would centralize all the board's firmware in one component. 2. "serial execution" - The SSFDC card can only do one thing at a time, so this doesn't seem to be an issue. 3. "isolate the other devices" - as I read your earlier paragraphs, the whole point of this exercise is to isolate/abstract the memory subsystem from the rest of the system. > >a microcontroller makes a system automatically "complex" or non-"flexible", > >any more than an FPGA or CPLD does. > > We're already going to need one of those devices anyway. Adding a > microcontroller will thus definitely mean adding a part, interfacing, etc. OK; that's a good reason. > What I mean by "flexible" is, an FPGA/CPLD not only can be anything you want, > but it can suddenly become something else, if that's what you need. A > microcontroller has a definite instruction set and hardware layout, which Well yes, but everything - including your FPGA/CPLD - has limits. > flexible. Can you outline where the compelling benefits to a microcontroll er > might be? That very much depends; I still can't understand what you're trying to design :) I'm probably misunderstanding, but it seems that you're trying to satisfy mutually exclusive objectives. If you just want to abstract the signal timing from the host, and it's acceptable for the host to know every detail of how to access SSFDC and implement the logical and physical format management in that external device, then that's going to be easy to do in your FPGA, trivial in fact, and I don't see why you need to outsource that IP. If you want to abstract the physical format management, then I think this will be more work and expense to implement in your FPGA than it will be to add a microcontroller. > > Or do you intend to turn this entire > >thing into an ASIC someday? > > Long-term, probably yes. I don't see uC's being a big issue here, however, as > plenty of uC producers offer versions available as ASIC cores (which they may I was just thinking in terms of die size limitations. > >URL in sig), I would suggest that it would be easier to use CompactFlash for > >a "boot" application... > > But doesn't the CompactFlash spec, in emulating a hard drive, impose > requirements on data formatting, communications protocols, etc? In other > words, does that not then require that you have a PROM and a rather rigidly > defined data interface? (lots of interface lines, with specific requirements What gives you the impression that a PROM necessary? And again, I'm confused - any storage medium, including your SSFDC card, requires that you comply with its interface, and CF's is in a lot of ways simpler than SSFDC's. A basic CF implementation (with 8-bit data bus) needs roughly the same number of I/O lines as an SSFDC implementation. (I can check our GPIO-lean design and give you an exact count if you want). Whatever storage medium you choose, the "socket end" of your device is going to have to live with "impose[d] requirements on data formatting, communications protocols, etc". Fundamentally, the CF card is just a series of numbered read/write storage blocks. So is the SSFDC card. However in the case of the CF card, you don't need to worry about buffering, wear leveling, defect management, logical-to-physical remapping, etc etc. because the microcontroller in the card will handle it for you. Whether you intended to handle that in your FPGA-system or in the system to which it talks, using CF offloads that work for you. In fact, the CF card is effectively the microcontrollered smart front-end-to-SSFDC-card that I was advocating if you had to use SSFDC as your media. To give a comparison between CF and SSFDC access: SS - Identify command - Returns arbitrary identification codes that need to be looked up in a ROMmed table. CF - Identify command - Returns explicit physical information about the media. SS - Read command - Works at the physical layer. Requires detailed information about the card block and page size. CF - Read command - Works at the logical layer. Defect management and wear leveling are automatic. SS - Write command - Works at the physical layer, atomic size variable from 256 to 528 bytes. Requires preceding erase command. Read-erase-write using external RAM (up to 16K) may be required. CF - Write command - Works at the logical layer, atomic size fixed at 512 bytes. Maximum size of required RAM buffer is 512 bytes. Or maybe you could just use linear SRAM PCMCIA cards - they're just battery-backed-up RAM chips, essentially :) -- -- Lewin A.R.W. Edwards Personal http://www.larwe.com/ Work http://www.digi-frame.com/ "... a man who is endowed with real qualities of leadership will be tempted to refrain from taking part in political life; because [...] the situation does not call for a man who has a capacity for constructive statesmanship but rather for a man who is capable of bargaining for the favour of the majority. Thus the situation will appeal to small minds and will attract them accordingly."Article: 32331
In article <3B32F4AA.7025F2D1@algor.co.uk>, rick@algor.co.uk says... > > > "Keith R. Williams" wrote: > > <snip> > > > ...and no, I'm *not* going to WinXP (at least until I start a new > > project). > > > > ... aren't you concerned that your XP system would be open to any hacker from age 10-100 ? Concerned? No, because I won't go there until instructed by my IS organization. I likely won't go there anyway (I never listen to the helpless desk). My point was that things *work* and I'm not going to even load a fixpack unless they don't. XP? You must be joking! Hey, I'm not happy being on Win2K, or NT4 before that, but that's where the tools are (Sun is out of the question, for some reason ;-). > Looking at the reports on XP I think it should be renamed, in the spirit of 56-bit DES, Win-NSA. They no > longer need to fight against strong encryption since they can just come on over & help themselves to your > keys. Well, since I was a developer of some DES-56 banking stuff (albeit over ten years ago), so I'll shrug the insult. ;-) > Why not go Linux instead ? Tools, mainly. Support is the secondary reason. I have real work to do. Installing and maintaining EDA applications is hard enough on Win and a stable platform. Installing Linux on this Laptop is unthinkable, even if all my apps ran there. I have real work to do and I'm a one- man show here. ---- KeithArticle: 32332
Amen to the real work to do and not having time to screw around with the tools/OS's. One question though, are you really doing your real work on a laptop? My experience is that the eda tools are an order of magnitude slower on a laptop (even a top of the line laptop) than on a decent NT workstation. For example a year and a half ago, I was surprised to discover that a place and route that ran in about 3.5 hours on a dual pentium pro 200 with 256 MB RAM took more than 24 hours to run on a 366MHz Tecra8000 with 128 MB RAM (I quit out on the 2nd day and ran it on the desk machine). The difference is apparently in the memory bandwidth and the speed of the hard drives. "Keith R. Williams" wrote: > > Why not go Linux instead ? > > Tools, mainly. Support is the secondary reason. I have real work to > do. Installing and maintaining EDA applications is hard enough on Win > and a stable platform. Installing Linux on this Laptop is unthinkable, > even if all my apps ran there. I have real work to do and I'm a one- > man show here. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 32333
Hi,
I am currently testing a VHDL design that derives a 2.048 MHz clock from
the 32.768 Mhz source. Below is a snippet of the code I am using. the part
is a Xilinx XC2S100:
--
-- 2.048 MHz clock generator
--
process(clk_reset,cnt1,clk_32768khz)
begin
if (clk_32768khz'event and clk_32768khz='1') then
if (clk_reset='0') or (cnt1=7) then
cnt1<=0;
else
cnt1<=cnt1+1;
end if;
end if;
end process;
process (clk_reset,cnt1,clk_32768khz,clk_2048khz)
begin
if (clk_32768khz'event and clk_32768khz='1') then
if (clk_reset='0') then
clk_2048khz<='0';
elsif (cnt1=7) then
clk_2048khz<=not(clk_2048khz);
end if;
end if;
end process;
I have done this many times before, is this the best way to create a clock?
Could some one comment on this and is there a better design that is
technology independent?
Article: 32334"Keith R. Williams" wrote: > In article <3B32F4AA.7025F2D1@algor.co.uk>, rick@algor.co.uk says... > > > > > > "Keith R. Williams" wrote: > > > > <snip> > > > > > ...and no, I'm *not* going to WinXP (at least until I start a new > > > project). > > > > > > > ... aren't you concerned that your XP system would be open to any hacker from age 10-100 ? > > Concerned? No, because I won't go there until instructed by my IS > organization. I likely won't go there anyway (I never listen to the > helpless desk). My point was that things *work* and I'm not going to > even load a fixpack unless they don't. > > XP? You must be joking! > My sentiments exactly. > > Hey, I'm not happy being on Win2K, or NT4 before that, but that's where > the tools are (Sun is out of the question, for some reason ;-). > > > Looking at the reports on XP I think it should be renamed, in the spirit of 56-bit DES, Win-NSA. They no > > longer need to fight against strong encryption since they can just come on over & help themselves to your > > keys. > > Well, since I was a developer of some DES-56 banking stuff (albeit over > ten years ago), so I'll shrug the insult. ;-) > Sorry no offense intended- I was just calling up the industry standard apocrypha that DES was designed with a back door trap and comparing it with this question: If XP having a permanent conversation with MS central is such an obvious security hole [it only takes a disgruntled employee or 2 to cause mayhem] why have they let it loose ? [behind this was the memory of 17 years ago when a project was held up for a couple of months while the encryption stuff was removed from a Unix port at the behest of, ultimately, the NSA. IIRC the crypto stuff originally supplied with BSD 4.1 Unix was too strong for their tastes and they (1) promoted the no-export legislation and (2) were trying to force 40-bit DES onto an unwilling public]. > > > Why not go Linux instead ? > > Tools, mainly. Support is the secondary reason. I have real work to > do. Installing and maintaining EDA applications is hard enough on Win > and a stable platform. Installing Linux on this Laptop is unthinkable, > even if all my apps ran there. I have real work to do and I'm a one- > man show here. > I can see that and its the same thing for me here - I'm the only h/w guy in a 5 man consultancy - and I'm refusing to install Win2K 'cos I don't know/trust it. My point about Linux, though, is this: In the last 6 years we have had from MS these o/s: Win3.1, Win95/98/ME, WinNT3/4, Win2K, and now WinXP. I believe MS's policy is to only support the current o/s and its predecessor so we can expect some time soon that WinNT support will go the way of 3.1. Not that support is much use but lack of it would mean the EDA vendors having an excuse to not support their tools if your o/s is not supported. In that time Linux has just been Linux. [why-oh-why didn't BSD have the same chance to catch on ?]. I don't want to make the jump myself, among other things I object to the ransom Mentor charge for Linux based tools, but I have a sneaking feeling that if I want real o/s stability I'll eventually have to go there.Article: 32335
I am looking for the VHDL model of " Intel 8279 "
" CD4060BC "
" CD4060BM "
" CD4060A "
" 74283 "
Could anyone help me ?? THANK YOU !!
Article: 32338In article <3B340E98.539886A2@andraka.com>, ray@andraka.com says... > Amen to the real work to do and not having time to screw around with the tools/OS's. One question though, are > you really doing your real work on a laptop? My experience is that the eda tools are an order of magnitude > slower on a laptop (even a top of the line laptop) than on a decent NT workstation. For example a year and > a half ago, I was surprised to discover that a place and route that ran in about 3.5 hours on a dual pentium > pro 200 with 256 MB RAM took more than 24 hours to run on a 366MHz Tecra8000 with 128 MB RAM (I quit out on the > 2nd day and ran it on the desk machine). The difference is apparently in the memory bandwidth and the speed of > the hard drives. Yes, I do almost all my work on this ThinkPad A21p. It is an 850MHz PII with 512MB memory though. I went mobile so I could work in the lab and the office with the expen$ive licensed/node-locked software. It's turned out quite well. The only thing that kept me on the desktop for a while was figuring out how to do dual displays. Win2K made that quite simple with a graphics card in a docking station feeding the secondary display. The worst resource hog is PAR, obviously. I've found that PAR is pretty much a function of the processor speed, given enough memory to keep disk accesses to a minimum. This laptop is about the same speed, or maybe a little faster than a 600MHz PIII Netfinity 5000 server (single CPU) I was using to off load PAR to before. ---- KeithArticle: 32339
In article <3B34469B.644C8BCE@algor.co.uk>, rick@algor.co.uk says... > > > "Keith R. Williams" wrote: > > > In article <3B32F4AA.7025F2D1@algor.co.uk>, rick@algor.co.uk says... > > > > > > > > > "Keith R. Williams" wrote: > > > > > > Looking at the reports on XP I think it should be renamed, in the spirit of 56-bit DES, Win-NSA. They no > > > longer need to fight against strong encryption since they can just come on over & help themselves to your > > > keys. > > > > Well, since I was a developer of some DES-56 banking stuff (albeit over > > ten years ago), so I'll shrug the insult. ;-) > > > > Sorry no offense intended- None taken. I thought it rather funny (see smiley). > I was just calling up the industry standard apocrypha that DES was designed with a > back door trap and comparing it with this question: If XP having a permanent conversation with MS central is > such an obvious security hole [it only takes a disgruntled employee or 2 to cause mayhem] why have they let it > loose ? > > [behind this was the memory of 17 years ago when a project was held up for a couple of months while the > encryption stuff was removed from a Unix port at the behest of, ultimately, the NSA. IIRC the crypto stuff > originally supplied with BSD 4.1 Unix was too strong for their tastes and they (1) promoted the no-export > legislation and (2) were trying to force 40-bit DES onto an unwilling public]. There was no back door trap. Quite the opposite really. The DES developers knew about differential-cryptanalysis and designed DES against it. Of course d-crypto was classified for another 20 years. Why do you think the NSA was afraid of DES for so long? There was no back door, at least in DES itself. Of course there no longer needs to be a back door since Moore's Law gave us a key to the front door. DES-40 wasn';t all *that* bad. It is as cryptographically strong as DES-56, just with a paper front door. ---- KeithArticle: 32340
"Keith R. Williams" wrote: > > In article <3B32F4AA.7025F2D1@algor.co.uk>, rick@algor.co.uk says... > > > > Why not go Linux instead ? > > Tools, mainly. This is one area that has recently improved dramatically. Synplicity, Cadence, Modelsim, Synopsis and many other smaller tool suppliers, all provide Linux tools now. If you haven't done so recently, take a look through the news and notes at: http://www.polybus.com/xilinx_on_linux.html The one weak link is of course the FPGA vendor tools, but several of these run just fine under Wine, including xilinx. > Support is the secondary reason. No question the Windoze tools will be better supported. > I have real work to > do. Installing and maintaining EDA applications is hard enough on Win > and a stable platform. Most of the Linux EDA tools specify Redhat 6.2. I would rate RH 6.2 as virtually rock solid. Certainly more solid than Windoze. > Installing Linux on this Laptop is unthinkable, > even if all my apps ran there. Linux runs great on most laptops, though trying to do EDA on a laptop... > I have real work to do and I'm a one- > man show here. I'm a one person company, and 99% of my work is done under Linux. Yes, you are going to spend more time screwing with the tools under Linux. But then screwing with the tools (especially FPGA vendor tools) has always been a part of EDA, so that really has not made that big of a difference to me. I decided to give Linux a try when I branched out on my own, having run EDA tools mostly on Unix at my previous employment. I have been nothing short of thrilled with the quality of it. On the other hand, if you do not have previous Unix experience, making the jump to Linux will certainly be much more difficult and time consuming. Duane Leeward EngineeringArticle: 32341
ModelSimPE GO 5.5B Foundation 3.3i GO SP8Article: 32342
Michael Dales <michael@dcs.gla.ac.uk> writes: As a follow up to my earlier posting, I discovered that using FPGA Express 3.2 my LUTs were not being processed properly. When I try to create an instance I get the warning: Warning: The net '/foo/lut_output' has no driver. Looking at the EDIF produced my LUTs are missing. This problem doesn't occur with FPGA Express 3.8. Is this a known problem or is it me doing something wrong? It's not particularly a problem as I can run it thru 3.8, but it would just be nice to know if I was doing something wrong. -- Michael Dales --- email: michael@dcs.gla.ac.uk --- tel: +44 141 330 6297 Department of Computing Science, University of Glasgow, Glasgow, G12 8QQArticle: 32343
In article <3B34C985.CD55786A@akamail.com>, dclark@akamail.com says... > "Keith R. Williams" wrote: > > > > In article <3B32F4AA.7025F2D1@algor.co.uk>, rick@algor.co.uk says... > > > > > > Why not go Linux instead ? > > > > Tools, mainly. > > This is one area that has recently improved dramatically. Synplicity, > Cadence, Modelsim, Synopsis and many other smaller tool suppliers, all > provide Linux tools now. If you haven't done so recently, take a look > through the news and notes at: > > http://www.polybus.com/xilinx_on_linux.html > > The one weak link is of course the FPGA vendor tools, but several of > these run just fine under Wine, including xilinx. Yes, I see Xilinx dragging their feet all the time. I was somewhat surprised to see Synplicity porting to Linux. I don't think they're quite there yet (Amplify?). My guess is that everyone is more afraid of support costs than they are of porting software. Have you looked at the cost of a Linux licenses? I know the Win Licenses are far cheaper than the various Unix licenses. > > Support is the secondary reason. > > No question the Windoze tools will be better supported. Windows support isn't great, but it is. > > I have real work to > > do. Installing and maintaining EDA applications is hard enough on Win > > and a stable platform. > > Most of the Linux EDA tools specify Redhat 6.2. I would rate RH 6.2 as > virtually rock solid. Certainly more solid than Windoze. Again, I'm not a WinLover, but this Win2K has been rock solid, at least since I got a Synplify dongle-driver that liked Win2K. > > Installing Linux on this Laptop is unthinkable, > > even if all my apps ran there. > > Linux runs great on most laptops, though trying to do EDA on a laptop... That's what I hear, but I'm not about to go screwing with a working system. Laptops tend to be strange beasts. > > I have real work to do and I'm a one- > > man show here. > > I'm a one person company, and 99% of my work is done under Linux. Yes, > you are going to spend more time screwing with the tools under Linux. > But then screwing with the tools (especially FPGA vendor tools) has > always been a part of EDA, so that really has not made that big of a > difference to me. I have little Unix experience (AIX) and that I didn't enjoy. However, Windows isn't a joy either. The widget I'm designing will be running under RedHat 6.2 on x86. I'm the one that pushed Linux as the OS (the last generation of hardware was hosted on RS/6000 and AIX), so it's not like I'm a Linus-phobe. ;-) > I decided to give Linux a try when I branched out on my own, having run > EDA tools mostly on Unix at my previous employment. I have been nothing > short of thrilled with the quality of it. On the other hand, if you do > not have previous Unix experience, making the jump to Linux will > certainly be much more difficult and time consuming. True. ---- KeithArticle: 32344
1) You need the library guide. Go here to download it. http://support.xilinx.com/support/sw_manuals/3_1i/download/ TC is Terminal Count" output and CEO is the same thing qualified by the CE pin. 2) I would just edit your CUPL code into VHDL. The Webpack schematic editor (ecs) allows you to embed a vhdl block into your design pretty easily. You can create as many extra chip select lines as you like and then connect to them as needed. I think ecs has a symbol generator that will read your vhdl and create a symbol for instantiation. 3) For fpga's you can assign the pins by running the design all the way through and then executing the constraints editor. It gives you the ability to assign pins as well as timing constraints I think. Sounds like you have a good handle on the things that need to be done. Good luck -- Pete Dudley Arroyo Grande Systems "Dean" <www@plexus-technologies.com> wrote in message news:3b337571.35836870@news.zip.com.au... > I'm just starting off with Webpack ISE and want to implement a counter in an > XC9572. I'm using the schematic editor and joining the blocks together, as > it were, and this is a really elegant way of doing things, but I have some > questions about how to accomplish certain things. I'm new at playing with > this (try "just got it this afternoon and I've got one day to do all of this > gee what fun") so please bear with me about what might seem obvious to you, > but new ground to me: > > 1) With the ADD SYMBOL action (F2), I see a list of building blocks to > choose from, but I can't seem to find exactly where the function and pin > definitions are. For example, I can see that a CB8CE is a Counter Binary > 8-bit with Clear and Enable by looking at the block diagram, but when I look > at the TC and CEO pins, I'd feel more comfortable if I knew the exact > definitions of their functions. I'm assuming TC is a carry input and CEO is > the carry output, but that's an assumption. Doesn't seem to be any > definitions file for these library objects anywhere, so can anyone point me > in the right direction in this regard? How do I inspect the formal > definitions? > > 2) One of the other chips on my test board is a 22V10, being used as an > address decoder. I've done this the old fashioned way with WinCUPL and the > equations below: > > > /** Inputs **/ > > PIN [3..7,9..13,16,27,26] = [A0..A4,A16..A23]; /* System addresses A0 - A23 > */ > PIN 2 = !AES; /* Address Enable Strobe */ > > > /** Outputs **/ > > PIN 17 = !CE0; /* SRAM BANK 0 */ > PIN 18 = !CE1; /* SRAM BANK 1 */ > PIN 19 = !CE2; /* SRAM BANK 2 */ > PIN 20 = !CE3; /* SRAM BANK 3 */ > PIN 21 = !ETH; /* ETHERNET CONTROLLER */ > PIN 23 = LCD_EN; /* LCD ENABLE LINE */ > PIN 24 = LATCHES; /* OUTPUT LATCHES */ > PIN 25 = LCD_RS; /* LCD REGISTER SELECT */ > > > /** Declarations and Intermediate Variable Definitions **/ > /** IMPORTANT NOTE: Memory Bank sizes are for the CY62128L 128kx8 SRAM **/ > > field IOADDR = [A23..A16, A4..A0]; > BANK0 = IOADDR:[200000..21FFFF]; > BANK1 = IOADDR:[220000..23FFFF]; > BANK2 = IOADDR:[240000..25FFFF]; > BANK3 = IOADDR:[260000..27FFFF]; > ETHERNET = IOADDR:[400000..40000E]; > AUX_IO = IOADDR:[600000]; > > > /** Logic Equations **/ > > CE0 = AES & BANK0; > CE1 = AES & BANK1; > CE2 = AES & BANK2; > CE3 = AES & BANK3; > ETH = AES & ETHERNET; > LATCHES = AES & AUX_IO; > > > As you can see, nothing much in it. Now what I'd like to do is throw away > the 22V10, and instead "insert" this address decoder into a corner of the > new XC9572 design. But I'd also like to extend the address space for it, so > that the original output select lines still go to individual pins to the > outside world as before, but now we also have some extra I/O decode lines > covering more addresses, which go internally to the blocks I'm adding in the > schematic editor. In other words, we still have the six original output > decode lines strobing I/O devices outside, but also have say an extra 6 or > 12 output decode lines controlling enable inputs or whatever, to the counter > elements I'm designing in the main part of the XC9572 How do I do this? My > hunch is that I can take the WinCUPL equations above and somehow create a > library block or element which I then place into the Schematic Editor and > run wires and buses to just like I'm doing with the blocks I'm taking from > ECS_CPLD.lib. > > Is this the case? If so, how do I do this, and if not, what is the correct > procedure? > > 3) How do I assign the chip's pins to the buses and wires I've got going > into/coming out of the blocks? I've tried adding an I/O marker to the end of > wires and buses which already have labels on them but it doesn't work. > > Due to my being thrown into the deep end on this as a rush job, I'm sure the > answers to all the above are in the on-line help, but I don't have the > luxury of time to read it from front to back, so I'm asking for any help to > get me up and running quickly - just the stuff I need to know for now, as it > were. > > Any help appreciated. I'll go into guru mode later - for now all I need is a > simple counter for measuring +ve and -ve pulse widths, and some I/O decode > to get at it all. >Article: 32345
"William Wallis" <w_f_wallis@yahoo.co.uk> wrote in message news:37bf59f.0106220447.6c4f9214@posting.google.com... > Why is it that in the UK Altera Devices are not only > difficult to acquire but are also very expensive? Is > this the same in other countries? I don't have any problems getting small quantities from Impact-Memec. LeonArticle: 32346
On Sat, 23 Jun 2001 14:43:10 -0600, "pete dudley" <padudle@spinn.net> wrote: >1) You need the library guide. Go here to download it. >http://support.xilinx.com/support/sw_manuals/3_1i/download/ >TC is Terminal Count" output and CEO is the same thing qualified by the CE >pin. OK done this - useful stuff. One question on this however. The section in Appendix B lists what you have to choose from, but for example the definitions for TC and CEO do not appear anywhere. Is this assumed knowledge? Just being cautious - don't want to be in the situation where I'm assuming an enable line on something is an active low rather than an active high. How do I make sure? >2) I would just edit your CUPL code into VHDL. The Webpack schematic editor >(ecs) allows you to embed a vhdl block into your design pretty easily. You >can create as many extra chip select lines as you like and then connect to >them as needed. I think ecs has a symbol generator that will read your vhdl >and create a symbol for instantiation. OK can anyone give me a 5-minute dummy's guide on how to do a cut'n'paste from my equations into a VHDL file so that I can create such a symbol? This is my first foray into VHDL. All I need to do is generate the address decoder I had in my old 22V10.Article: 32347
On Sat, 23 Jun 2001 14:43:10 -0600, "pete dudley" <padudle@spinn.net> wrote: >1) You need the library guide. Go here to download it. >http://support.xilinx.com/support/sw_manuals/3_1i/download/ >TC is Terminal Count" output and CEO is the same thing qualified by the CE >pin. OK done this - useful stuff. One question on this however. The section in Appendix B lists what you have to choose from, but for example the definitions for TC and CEO do not appear anywhere. Is this assumed knowledge? Just being cautious - don't want to be in the situation where I'm assuming an enable line on something is an active low rather than an active high. How do I make sure? >2) I would just edit your CUPL code into VHDL. The Webpack schematic editor >(ecs) allows you to embed a vhdl block into your design pretty easily. You >can create as many extra chip select lines as you like and then connect to >them as needed. I think ecs has a symbol generator that will read your vhdl >and create a symbol for instantiation. OK can anyone give me a 5-minute dummy's guide on how to do a cut'n'paste from my equations into a VHDL file so that I can create such a symbol? This is my first foray into VHDL. All I need to do is generate the address decoder I had in my old 22V10.Article: 32348
On Sat, 23 Jun 2001 14:43:10 -0600, "pete dudley" <padudle@spinn.net> wrote: >1) You need the library guide. Go here to download it. >http://support.xilinx.com/support/sw_manuals/3_1i/download/ >TC is Terminal Count" output and CEO is the same thing qualified by the CE >pin. > OK thanks - done. >2) I would just edit your CUPL code into VHDL. The Webpack schematic editor >(ecs) allows you to embed a vhdl block into your design pretty easily. You >can create as many extra chip select lines as you like and then connect to >them as needed. I think ecs has a symbol generator that will read your vhdl >and create a symbol for instantiation. OK can anyone give me a 5-minute dummy's guide on how to do a cut'n'paste from my equations into a VHDL file so that I can create such a symbol? This is my first foray into VHDL. All I need to do is generate the address decoder I had in my old 22V10.Article: 32349
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