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 24200

Article: 24200
Subject: Re: Variable shifting
From: Ray Andraka <ray@fpga-guru.com>
Date: Sat, 29 Jul 2000 06:58:19 GMT
Links: << >>  << T >>  << A >>


rickman wrote:

> I am not clear as to what you are saying. Do you mean that the signal
> from an F/G LUT will go to the F5 mux as well as to some other
> destination? I don't think this is correct. The architecture I assumed
> did not use the same structure when using the 4 input mux. The output of
> the 4 input mux is from the F5 mux and the F/G LUTs do not leave the CLB
> rather they go directly to the F5 mux and only to the F5 mux.

If you do the 2x2 merged tree, then the F/G outputs each go to two places.  One would the F5, the
other is to a 2 input mux somewhere else.  If you are not taking those outputs, then you are building
with a basic block of a 4 input mux, in which case you need one 4 input mux (one slice) for each bit
in the output.  As you observed yesterday, this quickly becomes inefficient as the width increases.

>
>
> Actually, that might be a third way to do this. Can you use the F5 mux
> in a Virtex or Spartan II and still access the outputs from the F LUT
> and G LUT? If so, then using the F5 mux as a 2 input mux in the original
> 2 input mux tree arrangement will reduce the number of CLBs by 1/3 in
> addition to helping somewhat with the routing.

You can get one of them out easily, but not both.  Techically, you cna get the second out the XB or YB
output by using the carry chain, but that requires the CLB below to drive a '1' into the carry in,
which means you're not getting the density anyway

>
>
> I did not consider the 4K series since there is not much point in using
> them in a new design. I expect they will be very pricey compared to what
> Xilinx is selling this time next year; Spartan III perhaps?

True enough, although consider the original spartan is also a 4K architecture.  Still, Xilinx calls
the 4K structure obsolete.  (In many ways it is more flexible, and is certainly denser than Virtex but
it is also less forgiving of sloppy design)


Article: 24201
Subject: Re: Virtex DLL problem.
From: murray@pa.dec.com (Hal Murray)
Date: 29 Jul 2000 07:16:49 GMT
Links: << >>  << T >>  << A >>

> I am no expert when it comes to Virtex but you seem to have interpreted the
> data sheet differently to me.


You can learn a lot about how things work and/or what it
possible by playing with the FPGA Editor.  I usually keep
a toy design around for this purpose.

If you can see a way to wire up what you want, there is probably
a way to get the tools to make it happen.  If you can't figure
out how to wire up what you want it probably isn't possible.

-- 
These are my opinions, not necessarily my employers.  I hate spam.

Article: 24202
Subject: Re: Viewlogic Licencing
From: rk <stellare@nospamplease.erols.com>
Date: Sat, 29 Jul 2000 07:07:35 -0400
Links: << >>  << T >>  << A >>
rickman wrote:

> At the time I had the problem, they were insistent that they had to do
> it this way to "protect" their interests. They just couldn't "get it"
> that this is such a major PITA that it actually prevented us from buying
> more of the full up board stations. I never did "get it" why they couldn't
> figure out a way to allow FPGA designs developed on *any* station to be used
> and reworked on *any* station licened for FPGA development. They seemed to
> think that the one way nature of transfering designs was an acceptable
> limitation.

I had long conversations with them about this.  It doesn't seem technically
hard to solve but they were just totally insistent on the way they were doing
things.   At day job, this cost me a lot of money, since it essentially made
existing one-product licenses useless; I had to upgrade them to full licenses
even though the engineers using them only used the capabilities of the
one-product license.  It seemed to me to be totally ridiculous that two
designers working on the same chip sitting right next to each other couldn't
share files.

Of course, every time I upgrade the software it's a game of Russian roullette
- I know something that did work before will now be broken.  As a policy, I
never upgrade any of the software unless I absolutely have to.  Recently,
something crashed and the viewlogic system became unusable (7.3x).  So I
loaded a slightly more modern version (7.5x I believe) and it all works great
except that it won't simulate anything.  GROAN!!!!!!!!!!

----------------------------------------------------------------------
rk
stellar engineering, ltd.        Once again, we were lucky - but luck
stellare@erols.com.NOSPAM        has no business in spaceflight.
Hi-Rel Digital Systems Design    -- Gene Kranz

Article: 24203
Subject: Re: Microprocessors in FPGA
From: nospam@lizard.net
Date: Sat, 29 Jul 2000 22:39:32 +1000
Links: << >>  << T >>  << A >>
look at http://www.rdrop.com/~cary/html/vlsi.html

On Thu, 1 Jun 2000 00:08:41 +0200, "Domagoj" <domagoj@engineer.com>
wrote:

>Hi,
>    Does anybody have any data about cost/performance as a function
>of performance (MIPS)  for microprocessors in FPGA ?
>
>Any information about processors in fpga would be highly appreciated.
>
>thanks,
>-------------------------------------------
>-             Domagoj              -
>- Domagoj@engineer.com -
>-------------------------------------------
>

Article: 24204
Subject: Spartan-II / Virtex-E / DC linear regulators
From: Laurent Gauch <laurent.gauch@aps-euro.com>
Date: Sat, 29 Jul 2000 09:46:29 -0400
Links: << >>  << T >>  << A >>
Hi all,

On my new embedded design, I have a Spartan-II XC2S200 and a Virtex-E
XCV1600E.

As this is an embedded product, I need some linear regulators, one for
3.3V, one for 2.5V and one for 1.8V.

Now my question is about my 2.5V and 1.8V DC linear regulators and about
current I need.

On the 2.5V I have VCCINT of Spartan-II XC2S200 and VCCO of Virtex-E
XCV1600E (1.5A or 3A).
On the 1.8V I have VCCINT of of Virtex-E XCV1600E (1.5A or 3A).

Now for both regulators, can I use a 1.5A DC linear regulator, or I need
to use a 3A DC linear regulator ( This question, because if I can use a
1.5A DC linear regulator I will save many places on my board).
Or maybe I need a 3A for the 2.5V (VCCINT of Spartan-II XC2S200 and VCCO
of Virtex-E XCV1600E),
and a1.5A for the 1.8V (VCCINT of of Virtex-E XCV1600E).

In limit case, what is the current max for the VCCINT of Spartan-II
XC2S200?
In limit case, what is the current max for the VCCO of Spartan-II
XC2S200?

In limit case, what is the current max for the VCCINT of Virtex-E
XCV1600E.
In limit case, what is the current max for the VCCO of Virtex-E
XCV1600E.

Thank you to let me know you experience!

Have a nice week-end.
Laurent


Article: 24205
Subject: Re: Variable shifting
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 29 Jul 2000 09:52:14 -0400
Links: << >>  << T >>  << A >>
Ray Andraka wrote:
> 
> rickman wrote:
> 
> > I am not clear as to what you are saying. Do you mean that the signal
> > from an F/G LUT will go to the F5 mux as well as to some other
> > destination? I don't think this is correct. The architecture I assumed
> > did not use the same structure when using the 4 input mux. The output of
> > the 4 input mux is from the F5 mux and the F/G LUTs do not leave the CLB
> > rather they go directly to the F5 mux and only to the F5 mux.
> 
> If you do the 2x2 merged tree, then the F/G outputs each go to two places.  One would the F5, the
> other is to a 2 input mux somewhere else.  If you are not taking those outputs, then you are building
> with a basic block of a 4 input mux, in which case you need one 4 input mux (one slice) for each bit
> in the output.  As you observed yesterday, this quickly becomes inefficient as the width increases.

Yes, the numbers I posted were for using 4 input muxes in a merged tree
without tapping into any intermediate signals within the mux. This uses
the same number of CLBs and uses *less* routing. So it does *not* get
inefficient as the width increases. Of course it is not useful for a
barrel shifter of width 2. But at all other widths, the 4 input mux is a
better solution.


> > I did not consider the 4K series since there is not much point in using
> > them in a new design. I expect they will be very pricey compared to what
> > Xilinx is selling this time next year; Spartan III perhaps?
> 
> True enough, although consider the original spartan is also a 4K architecture.  Still, Xilinx calls
> the 4K structure obsolete.  (In many ways it is more flexible, and is certainly denser than Virtex but
> it is also less forgiving of sloppy design)

What is more flexible about the 4K series. You once posted that the
carry chain is more flexible in the 4K than in the Virtex. Are there any
other features that are better in the 4K series? 


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24206
Subject: Re: Viewlogic Licencing
From: rickman <spamgoeshere4@yahoo.com>
Date: Sat, 29 Jul 2000 09:58:15 -0400
Links: << >>  << T >>  << A >>
Maybe I am just a contrarian, but I saw the licensing working the other
way. I would *only* buy the FPGA workstations since I needed to be able
to support the FPGA stations. Using a board station would make the
design incompatible with the rest of the world of FPGA stations.

Does anyone know if Viewlogic has fixed this problem? I guess I could
ask Viewlogic. 


rk wrote:
> 
> rickman wrote:
> 
> > At the time I had the problem, they were insistent that they had to do
> > it this way to "protect" their interests. They just couldn't "get it"
> > that this is such a major PITA that it actually prevented us from buying
> > more of the full up board stations. I never did "get it" why they couldn't
> > figure out a way to allow FPGA designs developed on *any* station to be used
> > and reworked on *any* station licened for FPGA development. They seemed to
> > think that the one way nature of transfering designs was an acceptable
> > limitation.
> 
> I had long conversations with them about this.  It doesn't seem technically
> hard to solve but they were just totally insistent on the way they were doing
> things.   At day job, this cost me a lot of money, since it essentially made
> existing one-product licenses useless; I had to upgrade them to full licenses
> even though the engineers using them only used the capabilities of the
> one-product license.  It seemed to me to be totally ridiculous that two
> designers working on the same chip sitting right next to each other couldn't
> share files.
> 
> Of course, every time I upgrade the software it's a game of Russian roullette
> - I know something that did work before will now be broken.  As a policy, I
> never upgrade any of the software unless I absolutely have to.  Recently,
> something crashed and the viewlogic system became unusable (7.3x).  So I
> loaded a slightly more modern version (7.5x I believe) and it all works great
> except that it won't simulate anything.  GROAN!!!!!!!!!!
> 
> ----------------------------------------------------------------------
> rk
> stellar engineering, ltd.        Once again, we were lucky - but luck
> stellare@erols.com.NOSPAM        has no business in spaceflight.
> Hi-Rel Digital Systems Design    -- Gene Kranz

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24207
Subject: QuickLogic programmer bits for sale
From: jesse@jumboprawn.net
Date: Sat, 29 Jul 2000 19:01:52 GMT
Links: << >>  << T >>  << A >>
Greetings -

We have a few (new) parts left for QuickLogic programming. Please see
http://www.jumboprawn.net/forsale/ql_100144.html
and
http://www.jumboprawn.net/forsale/ql_base.html
and make offer if you like.

thanks -
- jesse@jumboprawn.net


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24208
Subject: Re: Variable shifting
From: Ray Andraka <ray@fpga-guru.com>
Date: Sat, 29 Jul 2000 19:09:04 GMT
Links: << >>  << T >>  << A >>


rickman wrote:

> Ray Andraka wrote:
> >
> > rickman wrote:
> >
> > > I am not clear as to what you are saying. Do you mean that the signal
> > > from an F/G LUT will go to the F5 mux as well as to some other
> > > destination? I don't think this is correct. The architecture I assumed
> > > did not use the same structure when using the 4 input mux. The output of
> > > the 4 input mux is from the F5 mux and the F/G LUTs do not leave the CLB
> > > rather they go directly to the F5 mux and only to the F5 mux.
> >
> > If you do the 2x2 merged tree, then the F/G outputs each go to two places.  One would the F5, the
> > other is to a 2 input mux somewhere else.  If you are not taking those outputs, then you are building
> > with a basic block of a 4 input mux, in which case you need one 4 input mux (one slice) for each bit
> > in the output.  As you observed yesterday, this quickly becomes inefficient as the width increases.
>

OK, if you are using 4 input MUXs as your primitive, then your tree is a 4x4 tree (fan-in of 4, fan-out of
4) for it to work right. That means your area is the same as the 2x2 tree, but the fan out on each layer is
doubled (you have one 4 in mux for each bit, and each of those is connected to 4 muxes in the next layer).
Discounting routing and loading this would be a bit faster for an unpipelined rotator.  The routing can be a
little more congested, although as I pointed out before, those signals are probably already occupying the
channels anyway.  Pipelined, the 2x2 tree will still be faster, but will have twice the clock latency.  I
can see now that this does use a smaller number of routes.

>
> Yes, the numbers I posted were for using 4 input muxes in a merged tree
> without tapping into any intermediate signals within the mux. This uses
> the same number of CLBs and uses *less* routing. So it does *not* get
> inefficient as the width increases. Of course it is not useful for a
> barrel shifter of width 2. But at all other widths, the 4 input mux is a
> better solution.
>
> > > I did not consider the 4K series since there is not much point in using
> > > them in a new design. I expect they will be very pricey compared to what
> > > Xilinx is selling this time next year; Spartan III perhaps?
> >
> > True enough, although consider the original spartan is also a 4K architecture.  Still, Xilinx calls
> > the 4K structure obsolete.  (In many ways it is more flexible, and is certainly denser than Virtex but
> > it is also less forgiving of sloppy design)
>
> What is more flexible about the 4K series. You once posted that the
> carry chain is more flexible in the 4K than in the Virtex. Are there any
> other features that are better in the 4K series?

The carry chain in 4K is indeed more flexible, and in fact can be used without using the LUTs, leaving the
LUTs for other functionality( usually related).  Additionally, the 4K gives you a LUT on the second layer of
logic instead of a mux.  That in turn increases the flexibility of a CLB, plus you can use that LUT somewhat
independently of the 4LUTs.  In virtex, you tie up both 4 LUTs if you use the F5, even if the LUT is
programmed as a pass-thru.

>
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

Article: 24209
Subject: Re: Spartan-II / Virtex-E / DC linear regulators
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 29 Jul 2000 21:09:37 GMT
Links: << >>  << T >>  << A >>


Laurent Gauch wrote:

> <snip>

> In limit case, what is the current max for the VCCINT of Spartan-II
> XC2S200?
> In limit case, what is the current max for the VCCO of Spartan-II
> XC2S200?
>
> In limit case, what is the current max for the VCCINT of Virtex-E
> XCV1600E.
> In limit case, what is the current max for the VCCO of Virtex-E
> XCV1600E.
>

There is no meaningful answer to this question. The supply currents are all
the result of dynamically charging ( and discharging ) internal or external
capacitances. So the current is proportional to frequency, and depends
totally on your design type and size.
The "limit case" would be an unrealistic amount of current if you implement
a max size toggling shift register and clock it at 200+MHz.

BTW, don't forget that the forward drop of an appropriately large silicon
diode can generate 2.5 V from 3.3 V, or 1.8 V from 2.5 V, but it is of
course up to you to figure out the worst-case scenario...

Peter Alfke, Xilinx Applications

Article: 24210
Subject: Re: Viewlogic Licencing
From: "Austin Franklin" <austin@darkroom88.com>
Date: 30 Jul 2000 05:32:36 GMT
Links: << >>  << T >>  << A >>
> Since we use both OrCAD and Viewlogic tools, I have to say that OrCAD's
> entry tools are easier to use, and we are more productive when using
> them.  

I am sorry to sound so cynical if you are really serious, but I just can't
believe anyone would...COULD make that statement with a straight face, or
at least without a lot of inebriation...  OrCAD is undoubtedly the WORST
schematic 'scribbling' program I have ever used.  And the worst part is,
they charge a LOT for it!  If it was $99, I'd take it seriously.  I'd
rather use stone and chisel...

It has the worst text handling capabilities I have ever seen.  You can't
like up the text unless you do it all ONE way, and bus handling is just so
so bad.  And...what's with "off page connectors"?  What's the point?  Try
putting a net just on top of a bus that goes up...you can't!  You have to
do all sorts of little jaggies to go up, around and over...  And the list
goes on...

I personally find ViewDraw to be one of the best, if not the best schematic
drawing program out there...and I've used quite a few...  What were your
complaints with ViewDraw?

Sorry, I know this isn't the OrCAD bashing group...

Article: 24211
Subject: Re: Viewlogic Licencing
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 30 Jul 2000 02:14:14 -0400
Links: << >>  << T >>  << A >>
I am unclear on how you feel about Orcad, Austin. Do you like it or not?
Stop beating around the bush and tell us!  ;)


Austin Franklin wrote:
> 
> > Since we use both OrCAD and Viewlogic tools, I have to say that OrCAD's
> > entry tools are easier to use, and we are more productive when using
> > them.
> 
> I am sorry to sound so cynical if you are really serious, but I just can't
> believe anyone would...COULD make that statement with a straight face, or
> at least without a lot of inebriation...  OrCAD is undoubtedly the WORST
> schematic 'scribbling' program I have ever used.  And the worst part is,
> they charge a LOT for it!  If it was $99, I'd take it seriously.  I'd
> rather use stone and chisel...
> 
> It has the worst text handling capabilities I have ever seen.  You can't
> like up the text unless you do it all ONE way, and bus handling is just so
> so bad.  And...what's with "off page connectors"?  What's the point?  Try
> putting a net just on top of a bus that goes up...you can't!  You have to
> do all sorts of little jaggies to go up, around and over...  And the list
> goes on...
> 
> I personally find ViewDraw to be one of the best, if not the best schematic
> drawing program out there...and I've used quite a few...  What were your
> complaints with ViewDraw?
> 
> Sorry, I know this isn't the OrCAD bashing group...

I was the one complaining about how the Viewlogic licensing works, or at
least used to work. I am asking if it *still* works that way and if they
ever plan to fix it. The problem is that if I want to use a board design
station to edit FPGA schematics I can no longer share them with people
using FPGA workstations. 

This is a *major* problem for me since I will need to distribute my FPGA
designs to various customers. I can edit board schematics using any
package I want. But I have to support my Lucent ORCA FPGA designs with
the Viewdraw package. If I get a Viewdraw board package I am worried
that I will either have a lot of trouble with the FPGA support or will
have to maintain *two* Viewlogic workstations; one for boards and one
for FPGAs. 

This is just such a PITA!!! Maybe I will pay them with a check that is
only compatible with my bank if they don't run it through their bank
first? 


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24212
Subject: Re: Viewlogic Licensing
From: rickman <spamgoeshere4@yahoo.com>
Date: Sun, 30 Jul 2000 02:51:07 -0400
Links: << >>  << T >>  << A >>
I forgot to make a point that shows how silly this Viewlogic restriction
is. I long ago figured out that you can bring any VL schematic into any
VL workstation by creating a file with the same name and extracting the
key line. Copy this line into the file you are trying to move and it
will work on the new workstation! 

It is just the fact that I will have to do this every time I want to
send out a design to a customer that ticks me off. Then the first time I
forget, I will have lots of calls from people saying that they can't
read the files!!!


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24213
Subject: Re: OT: was: Re: Which one is good coding style?
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 30 Jul 2000 06:57:26 GMT
Links: << >>  << T >>  << A >>
>> You're eyes are on the left and right sides of your face.  If they
>> were, say, in the top and bottom of your face, then a mirror would
>> invert top & bottom!
>
>The mirror /doesn't/ invert left and right (or up and down or anything 
>else). The /user/ of the mirror does. Think about it.

That was pretty much my point.

>--
>Steve Rencontre          http://www.rsn-tech.co.uk
>//#include <disclaimer.h>

Article: 24214
Subject: Re: Which one is good coding style?
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 30 Jul 2000 07:09:02 GMT
Links: << >>  << T >>  << A >>
>Andy Peters wrote:

<snip>

>> and raise my rent!  

... implying that you're not in the Bay area.


>> What happens here is that the synth notices that rst1 is the global
>> reset. The P+R tools then use rst1 as GSR, and rst2 in flop is
>> actually used as a *synchronous* reset.  (Note that neither rst1 nor
>> rst2 were synced in an IFF.)

Are you sure it's a synchronous reset?  (You did put'*'s around it, so your 
probably sure.)  That means that the synth tools are rather changing the 
function of the design, giving me a rather worrying feeling.

This means, then, that if you do want to have the output of an asynchronous 
logic function reset a FF, and the output of a different asynch logic 
function reset a different logic function, you have to instatniate it "by 
hand"?

>> In any event, I think the best thing to do is to have one global async
>> reset, and use sync resets for your state machines and such to ensure
>> they get reset as you expect.

Hmm.  Won't work for my application.  I'm implementing a bunch of 1-shot 
timers in some unused space in a Xilinx FPGA.  When the input bit goes to 
'1', I asynchronously reset my counter to all '1's.  Then, I count down 
with a rather slow clock.  My output is all the bits of the counter 'or'ed 
together.

Since the input pulse can be really quick compared to my clock, and since 
I'm implementing about a dozen of these in one FPGA, does that mean that 
all of my asynch RST's are implemented synchronously?

-kent
Article: 24215
Subject: Free-running Oscillator.
From: korthner@hotmail.nospam.com (K. Orthner)
Date: 30 Jul 2000 08:40:39 GMT
Links: << >>  << T >>  << A >>
In the Spartan FPGAs, you can use the free-running oscillator used for 
configuration inside your design with the 'OSC4' primitive.

It's a very inaccurate oscillator, but good enough for what I'm doing.

I'd like to know if it's possible to do the same thing in a spartan-II 
device.  

I've tried simply retargeting the Spartan-II device, without changing the 
VHDl code at all, but I get a "the OSC4 symbol is not supported in the 
spartan2 architecture. ..." error during translation.

Thanks!

-Kent
Article: 24216
Subject: Re: LFSR as a divider
From: erika_uk@my-deja.com
Date: Sun, 30 Jul 2000 14:11:01 GMT
Links: << >>  << T >>  << A >>
hey,

i can't understand why many of you recommend the use of LFSR rather
than a simple counter. building a counter using the dedicated carry
logic will be much faster. although it's bit "rigid" because of the
carry logic, but if it's modulo 16, it will take nomore than 2 clb...

any comments please ...

In article <8lqlva$sns@inf-gw.inf.furukawa.co.jp>,
  "K.Orthner" <nospam@ihatespam.com> wrote:
> Assuming that you're not extremely short on space, you could buile a
LFSRout
> of regular FF's and logic blocks.  Because the logic for a LFSR is
much
> simpler that for a counter, it would still be able to run
significantly
> faster.
>
> The VHDL code would look something like this:
>
> process lfsr (rst, clk )
> begin
>   if rst = '1' then
>       lfsr_reg <= '1' & (others => '0');
>       -- Note: You have to reset the lfsr to non-zero.
>
>   elsif rising_edge( clk ) then
>       lfsr_reg <=  (lfsr_reg(0) xor lfsr_reg(2) ) & lfsr_reg
(lfsr_size-1
> downto 1);
>       -- Another note: This is going left-to-right.
>
>   end if;
> end process;
>
> You can then just AND together all of the bits of lfsr_reg, which
will give
> you a pulse when the entire LFSR is '1'.  (The all-zero state will
never
> happen).
>
> A length of 14 bits should give you a pulse once every 16383 clk
cycles.
>
> -Kent
>
> P.S.  I haven't read the app note, so my implementation may look
nothing at
> all like Xilinx's.
>
> > I have looked into using the LFSR setup described in Xilinx's
> > XAPP210 (By Maria George and Peter Alfke), and implementing it
> > looks simple enough.  The problem is that I don't see how one
> > gains access to all the bits in the LFSR.  I want to do something
> > like let the thing free run and output a pulse every time it
> > comes round to a particular state, say 0.
> >
> > Does anybody know how to do this?
>
> ------------
> Kent Orthner
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24217
Subject: Re: LFSR as a divider
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 30 Jul 2000 14:26:26 GMT
Links: << >>  << T >>  << A >>


erika_uk@my-deja.com wrote:

> hey,
>
> i can't understand why many of you recommend the use of LFSR rather
> than a simple counter. building a counter using the dedicated carry
> logic will be much faster. although it's bit "rigid" because of the
> carry logic, but if it's modulo 16, it will take nomore than 2 clb...
>

And if it's really a 4-bit modulo 16 counter, it would not even use the
carry logic, but rather the 4-input LUTs, and would run "full bore" at
>200 MHz.

Peter Alfke, Xilinx Applications

Article: 24218
Subject: Re: Which one is good coding style?
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 30 Jul 2000 14:43:03 GMT
Links: << >>  << T >>  << A >>


"K. Orthner" wrote:

> <snip>  I'm implementing a bunch of 1-shot
> timers in some unused space in a Xilinx FPGA.  When the input bit goes to
> '1', I asynchronously reset my counter to all '1's.  Then, I count down
> with a rather slow clock.  My output is all the bits of the counter 'or'ed
> together.

Pretty clever! If the trailing edge of asynchr. preset collides with the first
count clock, this problem gets resolved in the LSB only. It does not matter if
other bits are still being preset for a few nanoseconds, or have been released
earlier.

At first look I was worried about the notoriously dangerous parallel
resolution of an asynchronous interface, but your design is safe.

Peter Alfke, Xilinx Applications

Article: 24219
Subject: Virtex SelectMAP download from CPU problem
From: "Alun" <alun101@DELETEtesco.net>
Date: Sun, 30 Jul 2000 17:19:43 +0100
Links: << >>  << T >>  << A >>
I'm downloading an xcv1000 from a CPU but get no change on the DONE or
INIT_L pins ie they stay at 0 and 1 respectively. INIT_L responds OK to a
pulse on PROGRAM_L.

I've checked the data on a logic analyser and the start and end look correct
(I haven't checked all words). The data is bit swapped compared to a .bit
file as per Xilinx app note.

I am strobing CS_L and WRITE_L so that the config is done in two byte
bursts.  Both CS_L and WRITE_L strobe to 0 to write a byte, and both are 1
when not writng. CCLK is 30.72MHz. BUSY is n/c since CCLK is <50-MHz. Should
BUSY be tied high? I don't see why, it's output only according to the data
sheet. The startup clock is CCLK.
The programming mode is SelectMAP. I can configure OK with JTAG.
I'm going mad and  need ideas. This is the worst thing to debug since I
programmed a Zilog SCC back in 1987 - nothing happens until everything is
perfect.

thanks
Alun


Article: 24220
Subject: Re: LFSR as a divider
From: Ray Andraka <ray@fpga-guru.com>
Date: Sun, 30 Jul 2000 18:20:25 GMT
Links: << >>  << T >>  << A >>
The LFSR does run  considerably faster than a counter using the carry
chain, especially as the width of the counter increases.  The drawbacks
are that 1) the count sequence is not intuitive, and 2) generally speaking
you can't directly decode a particular state as fast as the counter runs.
However, you can pipeline the decode to get the performance back.  The
LFSR can save you some resources but even that is not as important as it
once was (you can use SRL16's if you don't need simultaneous access to all
the states, and generally only one LUT is needed.  BTW, you can still
decode a state, for instance to get a terminal count when using SRL16s by
looking at the N bit history.  Easiest is the decode of the all zeros
state, in which case you have a state machine that produces a '1' if the
input was '0' for the last N clocks.

erika_uk@my-deja.com wrote:

> hey,
>
> i can't understand why many of you recommend the use of LFSR rather
> than a simple counter. building a counter using the dedicated carry
> logic will be much faster. although it's bit "rigid" because of the
> carry logic, but if it's modulo 16, it will take nomore than 2 clb...
>
> any comments please ...
>
> In article <8lqlva$sns@inf-gw.inf.furukawa.co.jp>,
>   "K.Orthner" <nospam@ihatespam.com> wrote:
> > Assuming that you're not extremely short on space, you could buile a
> LFSRout
> > of regular FF's and logic blocks.  Because the logic for a LFSR is
> much
> > simpler that for a counter, it would still be able to run
> significantly
> > faster.
> >
> > The VHDL code would look something like this:
> >
> > process lfsr (rst, clk )
> > begin
> >   if rst = '1' then
> >       lfsr_reg <= '1' & (others => '0');
> >       -- Note: You have to reset the lfsr to non-zero.
> >
> >   elsif rising_edge( clk ) then
> >       lfsr_reg <=  (lfsr_reg(0) xor lfsr_reg(2) ) & lfsr_reg
> (lfsr_size-1
> > downto 1);
> >       -- Another note: This is going left-to-right.
> >
> >   end if;
> > end process;
> >
> > You can then just AND together all of the bits of lfsr_reg, which
> will give
> > you a pulse when the entire LFSR is '1'.  (The all-zero state will
> never
> > happen).
> >
> > A length of 14 bits should give you a pulse once every 16383 clk
> cycles.
> >
> > -Kent
> >
> > P.S.  I haven't read the app note, so my implementation may look
> nothing at
> > all like Xilinx's.
> >
> > > I have looked into using the LFSR setup described in Xilinx's
> > > XAPP210 (By Maria George and Peter Alfke), and implementing it
> > > looks simple enough.  The problem is that I don't see how one
> > > gains access to all the bits in the LFSR.  I want to do something
> > > like let the thing free run and output a pulse every time it
> > > comes round to a particular state, say 0.
> > >
> > > Does anybody know how to do this?
> >
> > ------------
> > Kent Orthner
> >
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Article: 24221
Subject: Re: Viewlogic Licensing
From: Ray Andraka <ray@fpga-guru.com>
Date: Sun, 30 Jul 2000 18:27:59 GMT
Links: << >>  << T >>  << A >>


rickman wrote:

> I forgot to make a point that shows how silly this Viewlogic restriction
> is. I long ago figured out that you can bring any VL schematic into any
> VL workstation by creating a file with the same name and extracting the
> key line. Copy this line into the file you are trying to move and it
> will work on the new workstation!
>
> It is just the fact that I will have to do this every time I want to
> send out a design to a customer that ticks me off. Then the first time I
> forget, I will have lots of calls from people saying that they can't
> read the files!!!

Which, if your customers are like mine might be two revisions of the tools
later :-)

Is the FPGA only thing even an issue anymore, now that VL isn't being
packaged with the FPGA tool suites from the vendors?  I do remember what a
PITA it was.

>
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

Article: 24222
Subject: OT: was Re: Which one is good coding style?
From: Andrew Cannon <ajc@gmx.net>
Date: Sun, 30 Jul 2000 23:47:47 +0200
Links: << >>  << T >>  << A >>
K.Orthner wrote:

> > You're welcome. I learnt something today too: nobody seems able to
> > explain me why left and right are inverted in a mirror but not top
> > and bottom ;-)
> 
> You're eyes are on the left and right sides of your face.  If they were,
> say, in the top and bottom of your face, then a mirror would invert top &
> bottom!
> 
> (Aren't I full of answers today!)


So what does a person with one eye see in a mirror?

...A
Article: 24223
Subject: Look-up tables in Altera
From: "Bernardino León" <bleon@lander.es>
Date: Sun, 30 Jul 2000 22:10:36 GMT
Links: << >>  << T >>  << A >>
One of the four inputs of the LUTs in the FLEX family is faster than the
three others.
Suppose we have a function like Y = A AND B AND C AND D, that fits in a
LUT... And suppossing that there isn't  any timing constrain in any of the
inputs
Is there any way to know - BEFORE compiling - which one of the four inputs
will be assigned the fastest of the four inputs?

Thanks
Bernardino Leon
bleon@lander.es



Article: 24224
Subject: Re: Foreign generated EDIF file in Foundation 2.1i
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Mon, 31 Jul 2000 00:47:12 +0100
Links: << >>  << T >>  << A >>


Hans wrote:

> I wonder if anybody can help me with the following problem, I have a
> component synthesised by Synplicity 6.0 which I would like to use as a
> black box component in a Foundation 2.1i project. I instantiate this black
> box component (EDIF) in a VHDL top level entity which I then synthesis (or
> try too) with FPGA express. The black box is synthesised without I/O ( I/O
> insertion disabled). I assumed that the back box EDIF and FPGA generated
> EDIF file would simply be merged into 1 big EDIF file, this doesn't seem
> to be happening.
>
> When I synthesis the top entity I get (FPGA-PADMAP-3) errors on the inout
> ports of the back box (all Out and In ports are OK).   Unfortunately
> Xilinx techdocs (http://support.xilinx.com/techdocs/3296.htm) did not
> provide me with a solution. There also seem to be some issue with the EDIF
> file bus notation as described in
> http://support.xilinx.com/techdocs/2649.htm, this also (adding the
> attribute to the Synplicity file) did not solve the problem.
>
> So my question is what steps are required to add a foreign generated EDIF
> file to a Foundation project?
>
> Thanks,
> Hans.

The best way to do this is probably to merge in the foreign EDIF file at the
NGDBUILD stage, keeping it as a black box during synthesis. This is easy if
you are running with the command line tools + make. Using the GUI you will
have to

o use the ``add file to project'' command or whatever its called to put the
EDIF in the right place in the hierarchy

o use a GUI feature that can add flags to the Xilinx commands as they are run.
The flag you need is the -sd one that points to a ``source directory'' where
you keep the foreign EDIF. I'm sorry its so long since I used the GUI that I
can't remeber the exact mechanics of this.





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