Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 32325

Article: 32325
Subject: SmartMedia controller available as CPLD/FPGA core?
From: arast@inficom.com (Alex Rast)
Date: Fri, 22 Jun 2001 20:49:16 GMT
Links: << >>  << T >>  << A >>
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.net

Article: 32326
Subject: Re: SmartMedia controller available as CPLD/FPGA core?
From: "Lewin A.R.W. Edwards" <larwe@larwe.com>
Date: Fri, 22 Jun 2001 21:38:28 GMT
Links: << >>  << T >>  << A >>
> 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
Subject: Re: SmartMedia controller available as CPLD/FPGA core?
From: arast@inficom.com (Alex Rast)
Date: Sat, 23 Jun 2001 00:14:14 GMT
Links: << >>  << T >>  << A >>
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.net


Article: 32328
Subject: Re: Unisim Library Question?
From: Ray Andraka <ray@andraka.com>
Date: Sat, 23 Jun 2001 00:38:31 GMT
Links: << >>  << T >>  << A >>
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.com



Article: 32329
Subject: Re: LFSR Taps for 64 bit registers?
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 23 Jun 2001 01:02:36 GMT
Links: << >>  << T >>  << A >>
>"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.

-- glen

Article: 32330
Subject: Re: SmartMedia controller available as CPLD/FPGA core?
From: "Lewin A.R.W. Edwards" <larwe@larwe.com>
Date: Sat, 23 Jun 2001 02:02:09 GMT
Links: << >>  << T >>  << A >>
> 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
Subject: Re: what tools run OK on windows 2000?
From: Keith R. Williams <krw@attglobal.net>
Date: Fri, 22 Jun 2001 22:05:56 -0400
Links: << >>  << T >>  << A >>
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.  


----

   Keith


Article: 32332
Subject: Re: what tools run OK on windows 2000?
From: Ray Andraka <ray@andraka.com>
Date: Sat, 23 Jun 2001 03:36:01 GMT
Links: << >>  << T >>  << A >>
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.com



Article: 32333
Subject: Clock Derivation
From: "mjd001" <mjd001@yahoo.com>
Date: Sat, 23 Jun 2001 00:25:59 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: what tools run OK on windows 2000?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 23 Jun 2001 08:34:51 +0100
Links: << >>  << T >>  << A >>


"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
(removed)


Article: 32336
(removed)


Article: 32337
Subject: Help me !! Please! (VHDL)
From: r9921110@ee.ntu.edu.tw (shin)
Date: 23 Jun 2001 04:31:31 -0700
Links: << >>  << T >>  << A >>
I am looking for the VHDL model of   " Intel 8279 "
                                     " CD4060BC "
                                     " CD4060BM "
                                     " CD4060A "
                                     " 74283 "
 Could anyone help me ?? THANK YOU !!

Article: 32338
Subject: Re: what tools run OK on windows 2000?
From: Keith R. Williams <krw@attglobal.net>
Date: Sat, 23 Jun 2001 11:40:26 -0400
Links: << >>  << T >>  << A >>
In 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.

----
  Keith 

Article: 32339
Subject: Re: what tools run OK on windows 2000?
From: Keith R. Williams <krw@attglobal.net>
Date: Sat, 23 Jun 2001 11:56:51 -0400
Links: << >>  << T >>  << A >>
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.

----
  Keith

Article: 32340
Subject: Re: what tools run OK on windows 2000?
From: Duane Clark <dclark@akamail.com>
Date: Sat, 23 Jun 2001 09:53:25 -0700
Links: << >>  << T >>  << A >>
"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 Engineering

Article: 32341
Subject: Re: what tools run OK on windows 2000?
From: sbob5757@aol.com (Sbob5757)
Date: 23 Jun 2001 17:22:48 GMT
Links: << >>  << T >>  << A >>

ModelSimPE       GO   5.5B
Foundation 3.3i         GO   SP8

Article: 32342
Subject: Re: Virtex LUT4 problems in FPGA Express
From: Michael Dales <michael@dcs.gla.ac.uk>
Date: 23 Jun 2001 19:19:40 +0100
Links: << >>  << T >>  << A >>
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 8QQ

Article: 32343
Subject: Re: what tools run OK on windows 2000?
From: Keith R. Williams <krw@attglobal.net>
Date: Sat, 23 Jun 2001 14:35:26 -0400
Links: << >>  << T >>  << A >>
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.

----
  Keith

  

Article: 32344
Subject: Re: Help needed: New user with Xilinx WebPack and XC9572 counter design - how to do basic things
From: "pete dudley" <padudle@spinn.net>
Date: Sat, 23 Jun 2001 14:43:10 -0600
Links: << >>  << T >>  << A >>
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
Subject: Re: ALTERA CHIPS - ANYBODY WANT TO BUY A "FEW" ONLY?
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Sun, 24 Jun 2001 00:21:06 +0100
Links: << >>  << T >>  << A >>

"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.

Leon



Article: 32346
Subject: Re: Help needed: New user with Xilinx WebPack and XC9572 counter design - how to do basic things
From: gerbil@zip.com.au
Date: Sun, 24 Jun 2001 03:04:01 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Help needed: New user with Xilinx WebPack and XC9572 counter design - how to do basic things
From: root@plexus-technologies.com (Dean Malandris)
Date: Sun, 24 Jun 2001 03:05:40 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Help needed: New user with Xilinx WebPack and XC9572 counter design - how to do basic things
From: root@plexus-technologies.com (Dean Malandris)
Date: Sun, 24 Jun 2001 03:11:37 GMT
Links: << >>  << T >>  << A >>
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
Subject: NEED VHDL DEBUGGER
From: "Mike Fisher" <mfisher@c4.com>
Date: Sun, 24 Jun 2001 03:34:52 GMT
Links: << >>  << T >>  << A >>






Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search