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 28650

Article: 28650
Subject: Re: FPGAs with a partial reconfiguration
From: Phil James-Roxby <phil.james-roxby@xilinx.com>
Date: Fri, 19 Jan 2001 09:50:05 -0700
Links: << >>  << T >>  << A >>
pawel5732@my-deja.com wrote:
> 
> Hi,
> What FPGAs do support a partial reconfiguration?
> What FPGAs can be reconfigured "on-the-fly"?
> Is this possible to use this feature with a tool?
> Thank you,
> Pawel
> 
> Sent via Deja.com
> http://www.deja.com/

The Atmel devices can be partially reconfigured, as can the Xilinx
Virtex devices (and their derivatives).  Tools are relatively few and
far between.  I don't know about the Atmel ones, I'll let Ulf deal with
that one.  Xilinx Virtex devices can be partially configured using the
JBits API, with details on the Xilinx website here
http://www.xilinx.com/products/jbits/index.htm
AFAIK, no 'mainstream' tool supports partial.
Phil 
-- 
---------------------------------------------------------------------
 __
/ /\/  Dr Phil James-Roxby         Direct Dial: 303-544-5545
\ \    Staff Software Engineer     Fax: Unreliable use email :-)
/ /    Loki/DARPA                  Email: phil.james-roxby@xilinx.com
\_\/\  Xilinx Boulder                 
---------------------------------------------------------------------

Article: 28651
Subject: Re: FPGAs with a partial reconfiguration
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 19 Jan 2001 08:53:37 -0800
Links: << >>  << T >>  << A >>
Pawel,

Virtex II is the first FPGA with internal access to the configuration
interface as a 'component' in verilog/vhdl and schematic.

The problem with it, is the same as always, how do you floorplan so you
don't step on yourself while reconfiguring?

The new 3.2i tools provide for floorplanning the designs, and pin
locking at the boundries, so we are excited to hear about people trying
out their dynamic reconfiguration ideas with Virtex II.

Admittedly, this isn't a well trod path, so there will be a lot of
expertise required to implement such designs.  But all of the 'hooks'
are there.

Austin

pawel5732@my-deja.com wrote:

> Hi,
> What FPGAs do support a partial reconfiguration?
> What FPGAs can be reconfigured "on-the-fly"?
> Is this possible to use this feature with a tool?
> Thank you,
> Pawel
>
> Sent via Deja.com
> http://www.deja.com/


Article: 28652
Subject: info about FPGA market?
From: Pawel <pawel5732@my-deja.com>
Date: Fri, 19 Jan 2001 16:57:46 GMT
Links: << >>  << T >>  << A >>
Hi,
Is there any on the Web site with a table or chart of "FPGA market
shares" - for free?
And how does it change during last years?
I've looked for, but I didn't find them, except "for registered people".
Thanks,
Pawel
--
Pawel Tomaszewicz
Warsaw University of Technology
00-665 Warsaw, Nowowiejska 15/19, Poland


Sent via Deja.com
http://www.deja.com/

Article: 28653
Subject: Re: FSM encoding
From: Luis Yanes <melus0@spamno.teleline.es>
Date: Fri, 19 Jan 2001 18:26:29 +0100
Links: << >>  << T >>  << A >>
On Thu, 18 Jan 2001 02:27:46 GMT Ray Andraka <ray@andraka.com> wrote:

>1) You might use the block rams in the XCV50 for the FSM, it will provide a
>faster machine, and 
>alot less sensitivity to changes in the state machine definition.  I think there
>may be a
>xilinx app-note on it.  The BRAM is used as a ROM that outputs the next state,
>plus any decoded outputs
>as a function of the current (encoded) state and some inputs.  If there are many
>inputs, they can usually
>be selected by a mux using the current state to reduce the number of address
>pins needed for the memory.

This is new way for the old style FSM made with a latch and EPROM as lookup
table that fills the whole possible 'state space'.

But with the distributed memory in the FPGA aproach there is holes in the
'state space', what hapens when an illegal state are reached? (due to
noise, bug, etc.). There is a predictable way of recover?.

I'm asking to implement the DCD DPLL FSM in FPGA I have in EPROM/lach.
( http://www.terra.es/personal2/melus0/gwlhw0n.html ).

Sorry if this is a stupid question, I've only done small FSMs. And I know
that when done with independent flip/flops something similar happens.
(A 17 state machine with 16 flip/flops).
73's de Luis

mail: melus0(@)teleline(.)es
Ampr: eb7gwl.ampr.org
http://www.terra.es/personal2/melus0/ <- PCBs for Homebrewed Hardware

Article: 28654
Subject: Re: FPGA for radar digital downconversion
From: tomderham@my-deja.com
Date: Fri, 19 Jan 2001 17:38:19 GMT
Links: << >>  << T >>  << A >>
Thanks to everyone for all the advice on this, I'm still doing research
trying to work out the exact specification and requirements, this info
and your websites help a lot.

Thanks again

Tom

In article <3A66E863.BB20E611@xilinx.com>,
  Ken Chapman <ken.chapman@xilinx.com> wrote:
> Dear Tom,
>
> In simple terms, this is about the required horsepower for the
application.
> If you can really perform all the processing that you need to in a
single
> DSP processor chip then it does provide you with a very easy way to
> prototype your system.
>
> However, at 50MHz sample rate you will soon burn up the available
number of
> MIPS available to you in a DSP processor. If we consider the
> TMS320VC5410-10 device, it has a single 17x17 multiplier clocked at
100MHz.
> This would only allow you to perform 2 operations at 50MHz. Obviously
you
> will be performing down-conversion to carry out most of your work at a
> lower sample rate, but this down-conversion in itself will almost
certainly
> require more than this 100MIPS. These processors are really excellent
when
> you have lots of time between samples such as in audio. At At 48KHz
the
> 100MIPS provides over 2000 operations per sample.


Sent via Deja.com
http://www.deja.com/

Article: 28655
Subject: Re: revision control tools ??
From: Doug Hillmer <doug.hillmer@innovisiontv.com>
Date: Fri, 19 Jan 2001 09:57:23 -0800
Links: << >>  << T >>  << A >>
I (Doug Hillmer) wrote:
> 
> 
> Any pointers on where I could get it would be
> welcomed.
> 

Here is the info for anyone who wants to check it
out:
 
    You may also visit my (future) web site:
        http://www.truebluesoftware.com

Article: 28656
Subject: Re: FSM encoding
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 19 Jan 2001 10:02:24 -0800
Links: << >>  << T >>  << A >>
Maybe this is "old hat", but here are my suggestions for a brute-force table-look-up
FSM in Virtex:

Use the 4K bit RAM, properly initialized during configuration. So it really is a
ROM, since you never write into it.
Use it as 512 x 8 ROM. Feed 5 of the 8 outputs back to the input and use the
remaining 4 inputs as control.
You now have a 32-state FSM with 4 condition inputs, and 3 extra arbitrarily decoded
outputs, beyond the 5 encoded outputs. You can define everything, like recovery from
illegal states, etc. No holes.

In Virtex-II the ROM is bigger, 18K bits.
So you can have a 128-state FSM with 4 control inputs, with the ROMconfigured 2K x
9.
Or 64 states with 5 control inputs.

Since these are synchronous dual-ported ROMs, you don't need any extra output or
input registers, and you can run at 200 MHz. Also, you automatically get two FSMs in
the same memory, both with the identical transition table, but individual control
inputs and individual clocking.

It's all pretty obvious once you think about it...
Peter Alfke, Xilinx Applications
========================================
Luis Yanes wrote:

> On Thu, 18 Jan 2001 02:27:46 GMT Ray Andraka <ray@andraka.com> wrote:
>
> >1) You might use the block rams in the XCV50 for the FSM, it will provide a
> >faster machine, and
> >alot less sensitivity to changes in the state machine definition.  I think there
> >may be a
> >xilinx app-note on it.  The BRAM is used as a ROM that outputs the next state,
> >plus any decoded outputs
> >as a function of the current (encoded) state and some inputs.  If there are many
> >inputs, they can usually
> >be selected by a mux using the current state to reduce the number of address
> >pins needed for the memory.
>
> This is new way for the old style FSM made with a latch and EPROM as lookup
> table that fills the whole possible 'state space'.
>
> But with the distributed memory in the FPGA aproach there is holes in the
> 'state space', what hapens when an illegal state are reached? (due to
> noise, bug, etc.). There is a predictable way of recover?.
>
> I'm asking to implement the DCD DPLL FSM in FPGA I have in EPROM/lach.
> ( http://www.terra.es/personal2/melus0/gwlhw0n.html ).
>
> Sorry if this is a stupid question, I've only done small FSMs. And I know
> that when done with independent flip/flops something similar happens.
> (A 17 state machine with 16 flip/flops).
> 73's de Luis
>
> mail: melus0(@)teleline(.)es
> Ampr: eb7gwl.ampr.org
> http://www.terra.es/personal2/melus0/ <- PCBs for Homebrewed Hardware


Article: 28657
Subject: Re: Alliance for Linux
From: Duane <junkmail@junkmail.com>
Date: Fri, 19 Jan 2001 10:14:54 -0800
Links: << >>  << T >>  << A >>
Jamie Lokier wrote:
> 
> Andy Peters writes:
> >> Andy Peters writes:
> >> > ModelSim and Synplify both use dongles (which I vastly prefer over
> >> > that FlexLM bogosity) but the Mac ain't got a parallel port so I'm SOL
> >> > there.
> >>
> >> And even if the MAC did have a parallel port...
> >>
> >> I vastly prefer FlexLM because there is some hope of it working in an
> >> emulator.  In my experience dongle reading code does seriously weird
> >> things to your parallel port, and doesn't work in an emulator.
> 
> > Yeah, but if FlexLM is keyed to your ethernet MAC (not Macintosh!)
> > address and you want to, say, do some work at home, you're hosed.
> 
> OTOH if you run it in an emulator, you get to choose the reported MAC
> addess :-)

If you are using VMware as your emulator, you can only choose part of
the MAC address. The rest is, unfortunately, fixed.

--
My real email is akamail.com@dclark (or something like that).

Article: 28658
Subject: Re: Best design for asyn. interface DSP <-> FPGA?
From: "Chris G. Schneider" <chris@cgschneider.com>
Date: Fri, 19 Jan 2001 21:40:50 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Chris, you may want to look at an article about crossing asynchronous
> clock boundaries that I published about a year ago. Mayeb it helps
> you.
>
> http://www.isdmag.com/editorial/2000/design0003.html
>
> Peter Alfke, Xilinx Applications
> ================================

Peter,

I have just reread your nice article. The asynchonous FIFO is a perfect
solution when it comes to streams of data that the FPGA processes.

In my application  FPGA registers are maped into the DSP memory. These
registers can set hardware switches, and in some cases the DSP data will
be
transfered to a synchronous FIFO through a pipeline, or the other way
round: data from an other FIFO can be read by the DSP as well.

Using synchronous FIFOs forced me to operate these FIFOs at the speed of

the DSP interface (120MHz), but the real data rates are much lower.

The fastest part in my design are the DSP interfaces, all other stuff is

much much slower.

The DSP is able to write to a register and read from it in the next
access. The effictive data rate of the DSP is about 25 MHz, but DSP
write strobes are very short (12 ns), and the DSP expects to valid data
23 ns after read assertion which is less than 3 clock cycles at 120 MHz.

This is the reason for choosing an asynchronous read access. But
unfortunately, async. logic can produce glitches, this may be a problem.

I don't know how to use async. FIFOs in this case. I cannot implement a
FIFO for each register bank, and the read after a write access makes the

use of FIFOs difficult.

I have to implement a lot of these kind of interfaces and I am looking
for a clean solution. May a cache build of BlockRAM be a possiblity?
My Virtex-E has some free RAM cells left. The DSP can have fast access
to the cache, and all write accesses to the registers can be pipelined
then. But what external clock can be used for this cache? There is just
the read and write signal of the DSP.

Originally I thought of this as a school book example, because mapping
FPGA registers into DSP memory seems to be pretty standard. I'm not sure

any more.

Best regards,

Chris



>
> "Chris G. Schneider" wrote:
>
>> I want to design an interface between a DSP and a FPGA. The DSP
>> should
>> be able to access FPGA registers, via the DSP parallel port. The
>> DSP parallel port has address, data, chip select, read and write
>> lines.
>> Just the usual stuff.
>>
>> I just designed this interface, but I am not happy with the results
>> in
>> terms of speed and design stability. So I  want to ask this audience
>> for
>> some design hints.
>>
>> 1) Write access: I just synchronize the DSP write signal and
>> generate an
>> internal write strobe to fetch the data. Is it a better solution to
>> use
>> the write signal to store the data in a register and then
>> synchronize
>> the register contents to the internal clock? This makes it possible
>> to
>> detect very short write strobes of the DSP and to reduce the number
>> of
>> WS, in the application.
>>
>> 2) Read access: I use a async. read access at the moment. Is it
>> possible
>> to make this work synchronously? The problem is that synchronizing
>> just
>> eats up a lot of time, and timing constraints of modern DSP are
>> pretty
>> tight. There will be a problem if the FPGA does not release the DSP
>> data
>> bus fast enough, because read and write accesses can appear very
>> soon
>> after each other.
>>
>> Any suggestions, or literature tips?
>>
>> --
>> chris
>



Article: 28659
Subject: Re: Virtex-II officially launched
From: Reinoud <dus@casema.net>
Date: Sat, 20 Jan 2001 00:54:30 +0100
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> By the way, good catch.  Thought you had us, didn't you?  We are not perfect
> (!!!! especially me), so if we do miss something, tell us right away,
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Flat packs.  Xilinx missed the importance of the small guy.

Bitstream specs.  Xilinx missed the significance of open source
phenomena.

That said, XC2V looks truly impressive - wonder if distributors
are going to have parts in stock within a year...

- Reinoud

Article: 28660
Subject: Re: Best design for asyn. interface DSP <-> FPGA?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 19 Jan 2001 16:25:31 -0800
Links: << >>  << T >>  << A >>
Chris,
the article I mentioned also describes, in the beginning, how to transfer a
single register across the clock boundary... Just in general terms, 120 MHz
and 12 ns are no longer scary values. Not for the recent Virtex-E and
Spartan-II devices, and definitely not for the newest Virtex-II, where
synchronous 24-bit counters can run at 300 MHz ( without allowing for
external delays).

Asynchronous FIFOs in either BlockRAMs or CLBs can run at 200 MHz, but to
generate reliable FULL and EMPTY handshake signals you must use Grey
counters, as described in our App note XAPP051 ( and if you want to use
that, send me an e-mail for newer improvements ).

It is impossible for me to evaluate all aspects of your design, but I want
to give you confidence that the newer chips are much faster than they were
in the past. And the most recent designs have amazed me.
Half a nanosecond is the new standard value for clock-to-Q, or set-up time,
or routing to the nearest CLB. And ripple-carry delay per bit are ten times
less.

Greetings
Peter Alfke, Xilinx Applications

=================================
"Chris G. Schneider" wrote:

> Peter Alfke wrote:
>
> > Chris, you may want to look at an article about crossing asynchronous
> > clock boundaries that I published about a year ago. Mayeb it helps
> > you.
> >
> > http://www.isdmag.com/editorial/2000/design0003.html
> >
> > Peter Alfke, Xilinx Applications
> > ================================
>
> Peter,
>
> I have just reread your nice article. The asynchonous FIFO is a perfect
> solution when it comes to streams of data that the FPGA processes.
>
> In my application  FPGA registers are maped into the DSP memory. These
> registers can set hardware switches, and in some cases the DSP data will
> be
> transfered to a synchronous FIFO through a pipeline, or the other way
> round: data from an other FIFO can be read by the DSP as well.
>
> Using synchronous FIFOs forced me to operate these FIFOs at the speed of
>
> the DSP interface (120MHz), but the real data rates are much lower.
>
> The fastest part in my design are the DSP interfaces, all other stuff is
>
> much much slower.
>
> The DSP is able to write to a register and read from it in the next
> access. The effictive data rate of the DSP is about 25 MHz, but DSP
> write strobes are very short (12 ns), and the DSP expects to valid data
> 23 ns after read assertion which is less than 3 clock cycles at 120 MHz.
>
> This is the reason for choosing an asynchronous read access. But
> unfortunately, async. logic can produce glitches, this may be a problem.
>
> I don't know how to use async. FIFOs in this case. I cannot implement a
> FIFO for each register bank, and the read after a write access makes the
>
> use of FIFOs difficult.
>
> I have to implement a lot of these kind of interfaces and I am looking
> for a clean solution. May a cache build of BlockRAM be a possiblity?
> My Virtex-E has some free RAM cells left. The DSP can have fast access
> to the cache, and all write accesses to the registers can be pipelined
> then. But what external clock can be used for this cache? There is just
> the read and write signal of the DSP.
>
> Originally I thought of this as a school book example, because mapping
> FPGA registers into DSP memory seems to be pretty standard. I'm not sure
>
> any more.
>
> Best regards,
>
> Chris
>
> >
> > "Chris G. Schneider" wrote:
> >
> >> I want to design an interface between a DSP and a FPGA. The DSP
> >> should
> >> be able to access FPGA registers, via the DSP parallel port. The
> >> DSP parallel port has address, data, chip select, read and write
> >> lines.
> >> Just the usual stuff.
> >>
> >> I just designed this interface, but I am not happy with the results
> >> in
> >> terms of speed and design stability. So I  want to ask this audience
> >> for
> >> some design hints.
> >>
> >> 1) Write access: I just synchronize the DSP write signal and
> >> generate an
> >> internal write strobe to fetch the data. Is it a better solution to
> >> use
> >> the write signal to store the data in a register and then
> >> synchronize
> >> the register contents to the internal clock? This makes it possible
> >> to
> >> detect very short write strobes of the DSP and to reduce the number
> >> of
> >> WS, in the application.
> >>
> >> 2) Read access: I use a async. read access at the moment. Is it
> >> possible
> >> to make this work synchronously? The problem is that synchronizing
> >> just
> >> eats up a lot of time, and timing constraints of modern DSP are
> >> pretty
> >> tight. There will be a problem if the FPGA does not release the DSP
> >> data
> >> bus fast enough, because read and write accesses can appear very
> >> soon
> >> after each other.
> >>
> >> Any suggestions, or literature tips?
> >>
> >> --
> >> chris
> >


Article: 28661
Subject: Re: Alliance for Linux
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 19 Jan 2001 17:03:56 -0800
Links: << >>  << T >>  << A >>
Duane <junkmail@junkmail.com> writes:
> If you are using VMware as your emulator, you can only choose part of
> the MAC address. The rest is, unfortunately, fixed.

Which is one reason why I intend to switch from VMware to Plex86 soon.
I don't begrudge the money I spent on VMware, as it's a pretty good
product, but I don't like their attitude that I shouldn't be allowed
to change some aspects of the configuration because they know what's
best for me.

Plex86 is no where near as fancy (yet), but it looks like it will do
what I want, and I can hack the source if necessary.

Article: 28662
Subject: Re: About programming cables
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 20 Jan 2001 01:17:26 +0000
Links: << >>  << T >>  << A >>


Nial Stewart wrote:

> John Grider wrote:
> >
> > "Juan M. Rivas" wrote:
> > >
> > > I'm looking for a Progrmming Cables from Xilinx, for a stand alone FPGA
> > > proyect:  Does anyone know wher I can by one, and which one is good?
> > >
> > > I've been looking for the Multilinx, and the Xcheqer,  but I can't
> > > decide...Besides I can't find where to find them (Always out of stock)
> > >
> > > Suggestions???
> > >
> > > Thanks all
> >
> > You could always build your own parallel/jtag cable - the schematics are
> > availible from xilinx's web site.  It looks simple, just two 74xxx's and
> > a couple diodes, caps, etc.
> > -- John
>
> Xilinx couldn't supply any more parrallel cable so the technician here
> built a few more.
>
> They work well and are _much_ faster than the multilinx cable (programming
> an xcv_1802 takes about 20 seconds as opposed to several minutes with the
> multilinx).
>
> Nial.

If you want a really simple way of doing it look at the apps note XAPP058. This
was orginally intended for an embedded micro-controller but the s/w is easy to
modify to drive a Win95/98 PC's parallel port. All you need then is a cable
with a Centronics D25 at one end & 4 flying wires at the other although it is
useful to buffer the JTAG on your board through an LS125. The associated s/w is
called eisp_4.06 & is somewhere in the downloads directory. We've been using it
off & on to allow users to update CPLDs on our board.

Its still much slower than the parallel-III cable or at least the V2.0 was,
maybe V4.06 has speeded up - we'll see next week.

Its even possible to do an NT version.


Article: 28663
Subject: Re: Synplicity newsgroup?
From: Andrew Dauman <andrew@synplicity.com>
Date: Fri, 19 Jan 2001 17:35:18 -0800
Links: << >>  << T >>  << A >>
The server was indeed down, but has been up as of 1/15.
If you are still having problems, please feel free to contact us
via email at support@synplicity.com and we will help.

Andrew


Muzaffer Kal wrote:

> Rick Filipkiewicz <rick@algor.co.uk> wrote:
>
> >
> >
> >Utku Ozcan wrote:
> >
> >> What happened to Synplicity's newsgroup?
> >> The newsgroup browser tells that the server is down...
> >>
> >> Utku
> >
> >I've never been able to get to it either - I contacted Synplicity about
> >this a long time ago but never got any result.
> >
> It's gone down just two days ago. There wasn't much traffic on it but
> I have been able to access to it till then. For a short while web site
> was down too but it came up, news didn't.
>
> Muzaffer
>
> FPGA DSP Consulting
> http://www.dspia.com

--

Andrew Dauman
Vice President of Corporate Applications
 Synplicity, Inc.
 935 Stewart Drive
 Sunnyvale, CA 94086
 Phone: 408-215-6000

E-mail: Andrew Dauman mailto:andrew@synplicity.com
Technical Support: mailto:support@synplicity.com



Article: 28664
Subject: Re: spartanII chip availability
From: Ray Andraka <ray@andraka.com>
Date: Sat, 20 Jan 2001 01:37:03 GMT
Links: << >>  << T >>  << A >>
The Atmel 40K would probably be a good match for this.  I wouldn't use them in 
most DSP apps because they lack a fast carry chain, making it hard to get 
anywhere near the performance/density of the Xilinx and Altera parts with fast
carry.
I've always had an issue with the "pin compatibility" claim of these parts, ever
since 
before they actually came out.

Pin compatibility in this case means that they can go into a xilinx 4K socket
without
making smoke, and if you are willing to do a complete redesign of the FPGA, you
can often
create an equivalent design.  The internal architectures are quite different. 
If Atmel
had the foresight (and perhaps the intellectual property rights) to put a carry
chain
in these parts, they would have been a decent competitor to the 4K parts that
were 
available on its introduction.  Xilinx came out with the Spartan line shortly
after Atmel
introduced the 40K, shattering Atmel's price point advantage.  Oh well...

Ulf Samuelsson wrote:
> 
> :     I am looking at building a small number 10-20 pcbs that will use one of
> : Xilinx's FPGAs.  The logic required is small but may be expanded later.
> : Essentially it is a FPDP i/f feeding some fifos that are feeding a D/A.
> :
> :     I am looking initially at a Spartan II for a fifo or DPRAM to hold some
> : data for the D/A.
> : I like the idea of using the block ram for the small DPRAM or fifo. Speed is
> : slow by most people's standards on this group. D/A will be run at 120KSa/s
> : or so but I am doing
> : 8 channels + on each FPGA.
> :
> You may want to try the Atmel AT40K FPGA family.
> They have "distribued" 10 ns SRAM suitable for FIFOs.
> There is a 32 x 4 DPRAM for every 16 macrocell,
> and they are hardwired, do not use configuration RAM.
> The AT94Kxx FPSLIC has 12kB of SRAM useable for the FPGA
> on  top of the distributed SRAM.
> They are pin compatible with the XC4000 series
> Tools are for free at Atmels homepage.
> The FPSLIC demoboard will set you back $500 for a 4 months
> license but then you get really good tools.
> Mentor Modelsim, Leonardo,Seamless.
> 
> --
> Best Regards
> Ulf at atmel dot com
> These comment are intended to be my own personal view
> and may or may not be shared by my Employer Atmel Sweden.

-- 
-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  or http://www.fpga-guru.com

Article: 28665
Subject: Re: FPGAs with a partial reconfiguration
From: Ray Andraka <ray@andraka.com>
Date: Sat, 20 Jan 2001 01:46:01 GMT
Links: << >>  << T >>  << A >>
Austin, a hook that I haven't seen yet is the ability to lock down the locations
of the ROUTING going in and out of a partial configuration overlay, as well as
the "fences" required to keep routing in or out of an area that is to be
partially reconfigured.  The only way around that I can see in the current tools
is painstaking hand routing in the FPGA editor.  Care to comment?



Austin Lesea wrote:
> 
> Pawel,
> 
> Virtex II is the first FPGA with internal access to the configuration
> interface as a 'component' in verilog/vhdl and schematic.
> 
> The problem with it, is the same as always, how do you floorplan so you
> don't step on yourself while reconfiguring?
> 
> The new 3.2i tools provide for floorplanning the designs, and pin
> locking at the boundries, so we are excited to hear about people trying
> out their dynamic reconfiguration ideas with Virtex II.
> 
> Admittedly, this isn't a well trod path, so there will be a lot of
> expertise required to implement such designs.  But all of the 'hooks'
> are there.
> 
> Austin
> 
> pawel5732@my-deja.com wrote:
> 
> ? Hi,
> ? What FPGAs do support a partial reconfiguration?
> ? What FPGAs can be reconfigured "on-the-fly"?
> ? Is this possible to use this feature with a tool?
> ? Thank you,
> ? Pawel
> ?
> ? Sent via Deja.com
> ? http://www.deja.com/

-- 
-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  or http://www.fpga-guru.com

Article: 28666
Subject: Re: FSM encoding
From: Ray Andraka <ray@andraka.com>
Date: Sat, 20 Jan 2001 01:52:22 GMT
Links: << >>  << T >>  << A >>
If you use the block RAM, it is the same as the old ROM based FSMs.  The whole
state space is covered, and in the VIrtex devices you have at least 8 address
bits to deal with.  If one is a muxed input, that leaves you with 128 states
plus a control input.  Change the BRAM to a handful of 4Kx1's and you get 2048
states plus one control.  This ought to cover a large majority of the cases. 
Note, this is not your father's distribute ram, these are the blcok rams found
in virtex and Altera 10 and 20K parts we're talking about in this case.  (of
course you could use the distributed RAM for smaller FSMs).

Luis Yanes wrote:
> 
> On Thu, 18 Jan 2001 02:27:46 GMT Ray Andraka ?ray@andraka.com? wrote:
> 
> ?1) You might use the block rams in the XCV50 for the FSM, it will provide a
> ?faster machine, and
> ?alot less sensitivity to changes in the state machine definition.  I think there
> ?may be a
> ?xilinx app-note on it.  The BRAM is used as a ROM that outputs the next state,
> ?plus any decoded outputs
> ?as a function of the current (encoded) state and some inputs.  If there are many
> ?inputs, they can usually
> ?be selected by a mux using the current state to reduce the number of address
> ?pins needed for the memory.
> 
> This is new way for the old style FSM made with a latch and EPROM as lookup
> table that fills the whole possible 'state space'.
> 
> But with the distributed memory in the FPGA aproach there is holes in the
> 'state space', what hapens when an illegal state are reached? (due to
> noise, bug, etc.). There is a predictable way of recover?.
> 
> I'm asking to implement the DCD DPLL FSM in FPGA I have in EPROM/lach.
> ( http://www.terra.es/personal2/melus0/gwlhw0n.html ).
> 
> Sorry if this is a stupid question, I've only done small FSMs. And I know
> that when done with independent flip/flops something similar happens.
> (A 17 state machine with 16 flip/flops).
> 73's de Luis
> 
> mail: melus0(@)teleline(.)es
> Ampr: eb7gwl.ampr.org
> http://www.terra.es/personal2/melus0/ ?- PCBs for Homebrewed Hardware

-- 
-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  or http://www.fpga-guru.com

Article: 28667
Subject: Re: FSM encoding
From: Ray Andraka <ray@andraka.com>
Date: Sat, 20 Jan 2001 01:56:31 GMT
Links: << >>  << T >>  << A >>


Peter Alfke wrote:
> 
> Maybe this is "old hat", but here are my suggestions for a brute-force table-look-up
> FSM in Virtex:
> 
> Use the 4K bit RAM, properly initialized during configuration. So it really is a
> ROM, since you never write into it.
> Use it as 512 x 8 ROM. Feed 5 of the 8 outputs back to the input and use the
> remaining 4 inputs as control.
> You now have a 32-state FSM with 4 condition inputs, and 3 extra arbitrarily decoded
> outputs, beyond the 5 encoded outputs. You can define everything, like recovery from
> illegal states, etc. No holes.

Peter, 

If you need more states, you can use a mux to select the appropriate condition
input for a given state.  In most cases,
you can reduce your condition inputs to the ROM to only one or maybe two
condition inputs.  Additional outputs can be had by installing parallel ROMs for
as many decoded outputs as you require.  

> 
> In Virtex-II the ROM is bigger, 18K bits.
> So you can have a 128-state FSM with 4 control inputs, with the ROMconfigured 2K x
> 9.
> Or 64 states with 5 control inputs.
> 
> Since these are synchronous dual-ported ROMs, you don't need any extra output or
> input registers, and you can run at 200 MHz. Also, you automatically get two FSMs in
> the same memory, both with the identical transition table, but individual control
> inputs and individual clocking.
> 
> It's all pretty obvious once you think about it...
> Peter Alfke, Xilinx Applications
> ========================================
> Luis Yanes wrote:
> 
> ? On Thu, 18 Jan 2001 02:27:46 GMT Ray Andraka ?ray@andraka.com? wrote:
> ?
> ? ?1) You might use the block rams in the XCV50 for the FSM, it will provide a
> ? ?faster machine, and
> ? ?alot less sensitivity to changes in the state machine definition.  I think there
> ? ?may be a
> ? ?xilinx app-note on it.  The BRAM is used as a ROM that outputs the next state,
> ? ?plus any decoded outputs
> ? ?as a function of the current (encoded) state and some inputs.  If there are many
> ? ?inputs, they can usually
> ? ?be selected by a mux using the current state to reduce the number of address
> ? ?pins needed for the memory.
> ?
> ? This is new way for the old style FSM made with a latch and EPROM as lookup
> ? table that fills the whole possible 'state space'.
> ?
> ? But with the distributed memory in the FPGA aproach there is holes in the
> ? 'state space', what hapens when an illegal state are reached? (due to
> ? noise, bug, etc.). There is a predictable way of recover?.
> ?
> ? I'm asking to implement the DCD DPLL FSM in FPGA I have in EPROM/lach.
> ? ( http://www.terra.es/personal2/melus0/gwlhw0n.html ).
> ?
> ? Sorry if this is a stupid question, I've only done small FSMs. And I know
> ? that when done with independent flip/flops something similar happens.
> ? (A 17 state machine with 16 flip/flops).
> ? 73's de Luis
> ?
> ? mail: melus0(@)teleline(.)es
> ? Ampr: eb7gwl.ampr.org
> ? http://www.terra.es/personal2/melus0/ ?- PCBs for Homebrewed Hardware

-- 
-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  or http://www.fpga-guru.com

Article: 28668
Subject: Re: Best design for asyn. interface DSP <-> FPGA?
From: Ray Andraka <ray@andraka.com>
Date: Sat, 20 Jan 2001 02:16:34 GMT
Links: << >>  << T >>  << A >>
It can be done without block rams.  Depending on what the registers hold, you
may not need synchronizing logic (a mode bit for instance often can be set
without timing consequence if the processor it controls is idle).  Let's assume
you need to write synchronously into a sytem with an async DSP write.  The DSP
write occurs on a write strobe that is async to any clocks you have.

What you do is let the DSP write pulse clock an input register(s) that
essentially gets written with the DSP data.  You might also want to write a few
bits of the address so you can figure out where the data is supposed to go.  So
far, we're not doing anything to get into the timing of our FPGA logic, this is
all self timed from the DSP (you may want to connect the write pulse to a clock
buffer).  For readback, internally select the register using just the address,
as it comes earlier, then turn on the output buffers with the qualified read.

Now, if you need the data syncrhonized to your FPGA clock, you toggle an
additional flip-flop with the write pulse, so that each time a write occurs, the
toggle flop changes to the opposite state.  You synchronize that toggle flop
output to the FPGA clock domain through a flip-flop or two, and then drive a
state machine that generates a 1 clock wide write pulse each time it sees that
synchronized toggle change state.  That write pulse can then be used to
synchronously and safely copy the data captured in the write register to another
register in your FPGA clock domain.  The only requirement is you have to
guarantee the capture register is not changed before the transfer occurs, which
can usually be done by making sure the local clock goes through at least 3 or 4
cycles in the fastest possible DSP write time (if not, you can assemble several
DSP writes into a long word and transfer only after the nth write).

Reading back can be a little trickier, but the same sort of set up can be used. 
Here, it helps if the read address is known ahead of time.


"Chris G. Schneider" wrote:
> 
> Peter Alfke wrote:
> 
> ? Chris, you may want to look at an article about crossing asynchronous
> ? clock boundaries that I published about a year ago. Mayeb it helps
> ? you.
> ?
> ? http://www.isdmag.com/editorial/2000/design0003.html
> ?
> ? Peter Alfke, Xilinx Applications
> ? ================================
> 
> Peter,
> 
> I have just reread your nice article. The asynchonous FIFO is a perfect
> solution when it comes to streams of data that the FPGA processes.
> 
> In my application  FPGA registers are maped into the DSP memory. These
> registers can set hardware switches, and in some cases the DSP data will
> be
> transfered to a synchronous FIFO through a pipeline, or the other way
> round: data from an other FIFO can be read by the DSP as well.
> 
> Using synchronous FIFOs forced me to operate these FIFOs at the speed of
> 
> the DSP interface (120MHz), but the real data rates are much lower.
> 
> The fastest part in my design are the DSP interfaces, all other stuff is
> 
> much much slower.
> 
> The DSP is able to write to a register and read from it in the next
> access. The effictive data rate of the DSP is about 25 MHz, but DSP
> write strobes are very short (12 ns), and the DSP expects to valid data
> 23 ns after read assertion which is less than 3 clock cycles at 120 MHz.
> 
> This is the reason for choosing an asynchronous read access. But
> unfortunately, async. logic can produce glitches, this may be a problem.
> 
> I don't know how to use async. FIFOs in this case. I cannot implement a
> FIFO for each register bank, and the read after a write access makes the
> 
> use of FIFOs difficult.
> 
> I have to implement a lot of these kind of interfaces and I am looking
> for a clean solution. May a cache build of BlockRAM be a possiblity?
> My Virtex-E has some free RAM cells left. The DSP can have fast access
> to the cache, and all write accesses to the registers can be pipelined
> then. But what external clock can be used for this cache? There is just
> the read and write signal of the DSP.
> 
> Originally I thought of this as a school book example, because mapping
> FPGA registers into DSP memory seems to be pretty standard. I'm not sure
> 
> any more.
> 
> Best regards,
> 
> Chris
> 
> ?
> ? "Chris G. Schneider" wrote:
> ?
> ?? I want to design an interface between a DSP and a FPGA. The DSP
> ?? should
> ?? be able to access FPGA registers, via the DSP parallel port. The
> ?? DSP parallel port has address, data, chip select, read and write
> ?? lines.
> ?? Just the usual stuff.
> ??
> ?? I just designed this interface, but I am not happy with the results
> ?? in
> ?? terms of speed and design stability. So I  want to ask this audience
> ?? for
> ?? some design hints.
> ??
> ?? 1) Write access: I just synchronize the DSP write signal and
> ?? generate an
> ?? internal write strobe to fetch the data. Is it a better solution to
> ?? use
> ?? the write signal to store the data in a register and then
> ?? synchronize
> ?? the register contents to the internal clock? This makes it possible
> ?? to
> ?? detect very short write strobes of the DSP and to reduce the number
> ?? of
> ?? WS, in the application.
> ??
> ?? 2) Read access: I use a async. read access at the moment. Is it
> ?? possible
> ?? to make this work synchronously? The problem is that synchronizing
> ?? just
> ?? eats up a lot of time, and timing constraints of modern DSP are
> ?? pretty
> ?? tight. There will be a problem if the FPGA does not release the DSP
> ?? data
> ?? bus fast enough, because read and write accesses can appear very
> ?? soon
> ?? after each other.
> ??
> ?? Any suggestions, or literature tips?
> ??
> ?? --
> ?? chris
> ?

-- 
-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  or http://www.fpga-guru.com

Article: 28669
Subject: Re: Synplicity newsgroup?
From: Ray Andraka <ray@andraka.com>
Date: Sat, 20 Jan 2001 02:20:46 GMT
Links: << >>  << T >>  << A >>
I still seems to be down.  Netscape is unable to locate the server
new.synplicity.com.  Worked before last week.  Hasn't worked at all this week. 
Did the server name change?

Andrew Dauman wrote:
> 
> The server was indeed down, but has been up as of 1/15.
> If you are still having problems, please feel free to contact us
> via email at support@synplicity.com and we will help.
> 
> Andrew
> 
> Muzaffer Kal wrote:
> 
> ? Rick Filipkiewicz ?rick@algor.co.uk? wrote:
> ?
> ? ?
> ? ?
> ? ?Utku Ozcan wrote:
> ? ?
> ? ?? What happened to Synplicity's newsgroup?
> ? ?? The newsgroup browser tells that the server is down...
> ? ??
> ? ?? Utku
> ? ?
> ? ?I've never been able to get to it either - I contacted Synplicity about
> ? ?this a long time ago but never got any result.
> ? ?
> ? It's gone down just two days ago. There wasn't much traffic on it but
> ? I have been able to access to it till then. For a short while web site
> ? was down too but it came up, news didn't.
> ?
> ? Muzaffer
> ?
> ? FPGA DSP Consulting
> ? http://www.dspia.com
> 
> --
> 
> Andrew Dauman
> Vice President of Corporate Applications
>  Synplicity, Inc.
>  935 Stewart Drive
>  Sunnyvale, CA 94086
>  Phone: 408-215-6000
> 
> E-mail: Andrew Dauman mailto:andrew@synplicity.com
> Technical Support: mailto:support@synplicity.com

-- 
-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  or http://www.fpga-guru.com

Article: 28670
Subject: Re: Synplicity newsgroup?
From: Andrew Dauman <andrew@synplicity.com>
Date: Fri, 19 Jan 2001 19:28:40 -0800
Links: << >>  << T >>  << A >>
Hi Ray,

It should be "news.synplicity.com",  can netscape see that?
The server name did not change, it may be a "cache" problem (i.e.
name mapping records are not all updated yet). If so, try 209.157.48.251,

Thanks
Andrew


Ray Andraka wrote:

> I still seems to be down.  Netscape is unable to locate the server
> new.synplicity.com.  Worked before last week.  Hasn't worked at all this week.
> Did the server name change?
>
> Andrew Dauman wrote:
> >
> > The server was indeed down, but has been up as of 1/15.
> > If you are still having problems, please feel free to contact us
> > via email at support@synplicity.com and we will help.
> >
> > Andrew
> >
> > Muzaffer Kal wrote:
> >
> > ? Rick Filipkiewicz ?rick@algor.co.uk? wrote:
> > ?
> > ? ?
> > ? ?
> > ? ?Utku Ozcan wrote:
> > ? ?
> > ? ?? What happened to Synplicity's newsgroup?
> > ? ?? The newsgroup browser tells that the server is down...
> > ? ??
> > ? ?? Utku
> > ? ?
> > ? ?I've never been able to get to it either - I contacted Synplicity about
> > ? ?this a long time ago but never got any result.
> > ? ?
> > ? It's gone down just two days ago. There wasn't much traffic on it but
> > ? I have been able to access to it till then. For a short while web site
> > ? was down too but it came up, news didn't.
> > ?
> > ? Muzaffer
> > ?
> > ? FPGA DSP Consulting
> > ? http://www.dspia.com
> >
> > --
> >
> > Andrew Dauman
> > Vice President of Corporate Applications
> >  Synplicity, Inc.
> >  935 Stewart Drive
> >  Sunnyvale, CA 94086
> >  Phone: 408-215-6000
> >
> > E-mail: Andrew Dauman mailto:andrew@synplicity.com
> > Technical Support: mailto:support@synplicity.com
>
> --
> -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  or http://www.fpga-guru.com

--

Andrew Dauman
Vice President of Corporate Applications
 Synplicity, Inc.
 935 Stewart Drive
 Sunnyvale, CA 94086
 Phone: 408-215-6000

E-mail: Andrew Dauman mailto:andrew@synplicity.com
Technical Support: mailto:support@synplicity.com



Article: 28671
Subject: How to be a more efficient productive FPGA designer ?
From: "Dan" <daniel.deconinck@sympatico.ca>
Date: Sat, 20 Jan 2001 04:03:16 GMT
Links: << >>  << T >>  << A >>
Hopefully we can get a good thread started on this useful subject. Please
contribute. We all would like to be more productive FPGA designers.

Obviously this varies with experience, technique and your tools etc.
Designers develope different approaches and habits.

Is there an optimal approach?

What are the pitfalls to avoid ?

Where does the time go? (or get wasted ?)  This is helpful to know, so these
areas can be focused on.

What important lessons have you learned ?

What are the best tools?


Sincerely
Daniel DeConinck
High Res Technologies, Inc.





Article: 28672
Subject: Re: How to be a more efficient productive FPGA designer ?
From: "Geoffrey G. Rochat" <geoff.nospam@nospam.pkworks.com>
Date: Sat, 20 Jan 2001 00:53:50 -0500
Links: << >>  << T >>  << A >>
Spend lots of time cruising newsgroups.  That helps productivity
immensely.



Article: 28673
Subject: Re: FPGAs with a partial reconfiguration
From: Pawel <pawel5732@my-deja.com>
Date: Sat, 20 Jan 2001 08:37:22 GMT
Links: << >>  << T >>  << A >>
In article <949ph3$kbq$1@nnrp1.deja.com>,
  pawel5732@my-deja.com wrote:
> Hi,
> What FPGAs do support a partial reconfiguration?
> What FPGAs can be reconfigured "on-the-fly"?
> Is this possible to use this feature with a tool?
> Thank you,
> Pawel
>
> Sent via Deja.com
> http://www.deja.com/
>
Thanks for information about Virtex. I've found some other AppNotes
about other chips: Orca2, Orca3 from Lucent, DY6000, DY8000 from
DynaChip. Does anybody have experience with partial reconfiguration
with these chips? What about tools to use this feature?
Do Altera's chips offer that feature?
Thanks,
Pawel

--
Pawel Tomaszewicz
Warsaw University of Technology
00-665 Warsaw, Nowowiejska 15/19, Poland


Sent via Deja.com
http://www.deja.com/

Article: 28674
Subject: Re: revision control tools ??
From: Petter Gustad <spam@gustad.com>
Date: 20 Jan 2001 10:04:45 +0100
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM writes:

> On 17 Jan 2001 15:35:10 +0100, Petter Gustad <dev.null@dev.null.org>
> wrote:
> 
> >What kind of functionality does MKS provide that CVS do not?
> 
> 3 things I can think of off-hand:

Thank you for the extensive reply.

> file manager, come to think of it). You get an immediate view of the
> whole project, you can see which files are modified, you can sort on

I do this from bash with an alias i have in my .bashrc file:
alias cvss='cvs status 2>/dev/null | grep Status: | grep -v Up-to-date'

I then type cvss on the top level of the source tree and get a list of
modified files or files which require a merge. In emacs I just type
C-x v d (sorry, I don't remember the command) and it will traverse the
source tree and give you the same information in an emacs buffer.

> tags, you can sort on modified files (irrespective of directory) so
> that you can check in all modded files at once, you can checkout only
> the required files without having to painfully remember and type each
> one, or creating a new module name for each set you're likely to want,

You can check in all modified files files in CVS by going to the top
of the source tree and type "cvs commit". I always keep the top of the
source tree in my bash directory stack, so going to the top of the
source tree is a matter of typing pushd.

> you can see who's got what file checked out, and a dozen other things.

This you can't do in CVS. I guess this is because you don't have locks
(i.e. reserved checkouts). See below.

> 2)
> The other obvious one - CVS doesn't have reserved checkouts. In fact,

This is sort of like a religion... I had used SCCS for quite a few
years and then RCS of some projects and I have to admit that I
disliked CVS for a while, mainly because the "anarchy" of no locks.
Now I'm used to it and I like it.

You don't into situations like: where is John, I need him to check in
the cpu.v file so I can fix a bug for the synthesis tonight, what,
he's sick, what's his password, where's the sysadmin with the root
password.. And what if John was working from the other side of the
globe and went on a four week snowboard vacation to Alaska. (I guess
some revision control systems has a local admin which might be
different from the root account to do these kinds of things)

As sombody has pointed out, you can enable locks with the cvs admin
command (actually you can do most RCS commands in CVS since its
repository handling is based upon RCS).

> I had an argument with someone recently who had used CVS on a large
> ASIC project, and their reply was that "this doesn't happen in
> practice". IMO, it will happen eventually, and the whole point of a
> management tool is to enforce systems to prevent this sort of thing
> happening.

Yes, this happens, and I never had any problems with it. Usually
people don't work on the same code segment within a file, so it
doesn't happen that frequently. If it does the last person to check it
in is responsible to make sure it's correct. Of course the CVS user
has to be aware of this, otherwise they will complain that their
Verilog simulator is broken, complaining about syntax errors on
>>>>>>>>>>> which I never typed in my code...

I never had this happen with binary files and machine generated files
since we don't have two people synthesising the design and checking in
the netlist. This is usually done by one person. But I see your point,
it would be smart to lock those files.

> you may want to make sure that only some people can create or delete
> archives. IMO, this is important when you have development groups with
> a large range of abilities in them (and in which only a few people, if
> any, have previously used a VCS).

You can do this with CVS too. It's done with lots of open source
projects where people from all over the world is working on a project.
The general user is not allowed to check in files, but can do updates
to get the latest source rather than to download the entire tarball. A
few key developers have write access and can check in and tag files...

A final note. I'm not saying that CVS is better than MKS. I can't
since I have never used MKS. I'm just making some comments based upon
my experience with CVS for several projects.

Petter
-- 
________________________________________________________________________
Petter Gustad            8'h2B | ~8'h2B            http://www.gustad.com
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}



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