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 48450

Article: 48450
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Thu, 17 Oct 2002 19:44:21 GMT
Links: << >>  << T >>  << A >>
Hi - 

On Thu, 17 Oct 2002 09:46:01 -0700, Peter Alfke <peter@xilinx.com>
wrote:

>
>
>Ray Andraka wrote:
>
>>  it would be nice to have an option to significantly slow the edges (even the 2mA drive has some
>> pretty fast edges) to help with SI and EMI on those designs where I/O speed needn't be really fast.
>> I'm not sure what the implications from a chip design standpoint would be.  If this
>> capability were available, then leaded packages wouldn't be the issue they are now with fast edges,
>> and you'd likely have a whole lot fewer SI cases to deal with.
>
>Ray,
>how slow do you want them to be ?
>I just kibitzed in Austin's office, and saw rise and fall times of 6 ns on a "2-mA"  output (fast and
>slow does not make a large difference at this "speed".)
>HyperLynx is really a fantastic tool  :-)
>
>Peter Alfke

It is a great tool.  But I just tried doing the same thing and got
different results.

I downloaded the latest Virtex-II IBIS models (9/6/2002) and set up
three driver/receiver pairs:

1) LVTTL2F driving 1-foot, 50-ohm trace, single LVTTL2F receiver.
2) LVTTL2S driving 1-foot, 50-ohm trace, single LVTTL2F receiver.
3) LVTTL2F driving  extremely short trace, single LVTTL2F receiver.

Case (3) looks great: a smooth, monotonic edge with a ~6ns risetime.
But if you look carefully at cases (1) and (2), you'll notice that the
waveforms at both the driving and receiving ends are a series of tiny
stairsteps, with the pedestals roughly the length of the round-trip
travel time on the line (somewhat shorter, actually).  In other words,
the LVTTL2x outputs look like fast-risetime devices with a high output
impedance.  Fine for a synchronous data or control signal, but
disastrous for a clock, at least if you're driving a trace of any
length.  (Anyone who has tried to distribute CCLK to multiple devices
without an external buffer has seen this.)

Normally, there's no way I would consider driving a foot-long trace
with a 2mA driver, at least not if I'm worried about monotonicity.
But it's a good way to distinguish between a truly slow-risetime
driver and a fast, high-output-impedance driver.

 By the way, in my simulation results, there's a significant
difference between the F and S drivers, at least at "typical."

I think what Ray's suggesting--a truly slow risetime driver--would be
useful for driving low-speed signals for long distances to multiple
receivers without worrying about termination.

Bob Perlman    

Article: 48451
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 17 Oct 2002 13:30:57 -0700
Links: << >>  << T >>  << A >>
Bob, the staircase just confirms what you and I have known for decades. That's what happens when your
output impedance is significantly larger than the line impedance.

And we all agree that it would be foolish to drive a foot-long clock line that way. That must absolutely
be terminated, either series or parallel.

But a non-critical data or control line should still be driven the 2-mA way, to minimize ground-bounce,
EMI, crosstalk and other devilish things.

Nice to hear from you again...  :-)
Peter Alfke
=========================

Bob Perlman wrote:

> Normally, there's no way I would consider driving a foot-long trace
> with a 2mA driver, at least not if I'm worried about monotonicity.
> But it's a good way to distinguish between a truly slow-risetime
> driver and a fast, high-output-impedance driver.
>
>  By the way, in my simulation results, there's a significant
> difference between the F and S drivers, at least at "typical."
>
> I think what Ray's suggesting--a truly slow risetime driver--would be
> useful for driving low-speed signals for long distances to multiple
> receivers without worrying about termination.
>
> Bob Perlman


Article: 48452
Subject: Re: How assingment of IOE by Quratus Ver2.1
From: "Georg" <N:A>
Date: Thu, 17 Oct 2002 23:32:27 +0200
Links: << >>  << T >>  << A >>

"momo" <shimo@atlas.riken.go.jp> wrote in message
news:65242e4e.0210170353.7ee1baa9@posting.google.com...
> Hi all
>
> I'm designing LCD Controller using ALTERA Quartus Ver2.1.
> I want to assign output FF signal to IOE register by Quartus Ver2.1.
> However, I don't know how to assign using this software.
You have to make a  I/O component embedding
in your code

COMPONENT altddio_out
 GENERIC (
  width  : NATURAL;
  power_up_high  : STRING;
  intended_device_family  : STRING;
  oe_reg  : STRING;
  extend_oe_disable  : STRING
 );
 PORT (
   dataout : OUT STD_LOGIC_VECTOR (0 DOWNTO 0);
   outclock : IN STD_LOGIC ;
   oe : IN STD_LOGIC ;
   datain_h : IN STD_LOGIC_VECTOR (0 DOWNTO 0);
   datain_l : IN STD_LOGIC_VECTOR (0 DOWNTO 0)
 );
 END COMPONENT;
Never rely on synthesis tool

Same thing goes for Xilinx


regards
Georg



Article: 48453
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Thu, 17 Oct 2002 21:40:16 GMT
Links: << >>  << T >>  << A >>
Peter - 

Ray said he thought that even the 2 mA driver was fast.  You said that
Hyperlynx showed that it was actually slow (6ns).   My point is that
the Virtex-II 2mA driver is not a slow driver; it's a fast but weak
(high-impedance) driver.  

There are applications where a truly slow, i.e., risetime-controlled
driver would be very useful.  For example, driving a long I2C bus
clock with an FPGA would be a lot easier if you offered a truly slow
driver.  If there were a driver that could drive a resistive load with
a 6ns risetime, then it could reliably drive, say, an 18-inch,
multi-drop I2C clock bus  (you'd actually use a slow open-drain
driver, but I digress).   

I'll post more often as soon as I can get 5.1i  working with my latest
design.  Don't wait up ... :-)

Bob Perlman 
Cambrian Design Works

On Thu, 17 Oct 2002 13:30:57 -0700, Peter Alfke <peter@xilinx.com>
wrote:

>Bob, the staircase just confirms what you and I have known for decades. That's what happens when your
>output impedance is significantly larger than the line impedance.
>
>And we all agree that it would be foolish to drive a foot-long clock line that way. That must absolutely
>be terminated, either series or parallel.
>
>But a non-critical data or control line should still be driven the 2-mA way, to minimize ground-bounce,
>EMI, crosstalk and other devilish things.
>
>Nice to hear from you again...  :-)
>Peter Alfke
>=========================
>
>Bob Perlman wrote:
>
>> Normally, there's no way I would consider driving a foot-long trace
>> with a 2mA driver, at least not if I'm worried about monotonicity.
>> But it's a good way to distinguish between a truly slow-risetime
>> driver and a fast, high-output-impedance driver.
>>
>>  By the way, in my simulation results, there's a significant
>> difference between the F and S drivers, at least at "typical."
>>
>> I think what Ray's suggesting--a truly slow risetime driver--would be
>> useful for driving low-speed signals for long distances to multiple
>> receivers without worrying about termination.
>>
>> Bob Perlman


Article: 48454
Subject: Re: Standing on the shores of Stratix-land
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 17 Oct 2002 17:57:20 -0400
Links: << >>  << T >>  << A >>
Bert Wibble wrote:
> 
> Interesting point about the Altera pricing. My company has
> traditionally always used Xilinx parts - and we have no complaints.
> Recently we spoke with Altera, and their pricing was far better than
> what Xilinx would offer for an equivalent part. But, typically, we
> have no time to invest in changing to an Altera part - so we end up
> staying with Xilinx because we know the parts - and pay more for them.
> I feel that maybe Xilinx trade on this point of view - and this allows
> them to keep their prices high. Thoughts ?

Last year I worked with a company who made a point of competing both
vendors on every design they started.  It actually hurt them a little
technically since they could not make use of special features on the
chips, but they felt in the long run it was a better way to go because
it made the chips cheaper.  I won't argue with the idea that you need to
use competition to get pricing down.  I will guarantee that you can get
better pricing out of your vendor if they know you can switch to
another.  But you have to make this threat believable.  

If the only thing holding you back is lack of familiarity with the
tools, perhaps you could do a new design using an outside consultant or
hire someone with experience with the tools?  

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 48455
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 17 Oct 2002 15:25:07 -0700
Links: << >>  << T >>  << A >>
Bob, I agree, but being a (good?) applications engineer, I try to find a work-around:
How's about an old-fashioned 100 pF capacitor to ground, right at the FPGA pin. That should smoothe out the
edge. Not elegant, clutters up the pc-board, but it should work, and anybody can do it today.
And the benefits of low ground-bounce, EMI, crosstalk etc. still apply.

Peter Alfke
=============
Bob Perlman wrote:

> Peter -
>
> Ray said he thought that even the 2 mA driver was fast.  You said that
> Hyperlynx showed that it was actually slow (6ns).   My point is that
> the Virtex-II 2mA driver is not a slow driver; it's a fast but weak
> (high-impedance) driver.
>
> There are applications where a truly slow, i.e., risetime-controlled
> driver would be very useful.  For example, driving a long I2C bus
> clock with an FPGA would be a lot easier if you offered a truly slow
> driver.  If there were a driver that could drive a resistive load with
> a 6ns risetime, then it could reliably drive, say, an 18-inch,
> multi-drop I2C clock bus  (you'd actually use a slow open-drain
> driver, but I digress).
>
> I'll post more often as soon as I can get 5.1i  working with my latest
> design.  Don't wait up ... :-)
>
> Bob Perlman
> Cambrian Design Works
>
> On Thu, 17 Oct 2002 13:30:57 -0700, Peter Alfke <peter@xilinx.com>
> wrote:
>
> >Bob, the staircase just confirms what you and I have known for decades. That's what happens when your
> >output impedance is significantly larger than the line impedance.
> >
> >And we all agree that it would be foolish to drive a foot-long clock line that way. That must absolutely
> >be terminated, either series or parallel.
> >
> >But a non-critical data or control line should still be driven the 2-mA way, to minimize ground-bounce,
> >EMI, crosstalk and other devilish things.
> >
> >Nice to hear from you again...  :-)
> >Peter Alfke
> >=========================
> >
> >Bob Perlman wrote:
> >
> >> Normally, there's no way I would consider driving a foot-long trace
> >> with a 2mA driver, at least not if I'm worried about monotonicity.
> >> But it's a good way to distinguish between a truly slow-risetime
> >> driver and a fast, high-output-impedance driver.
> >>
> >>  By the way, in my simulation results, there's a significant
> >> difference between the F and S drivers, at least at "typical."
> >>
> >> I think what Ray's suggesting--a truly slow risetime driver--would be
> >> useful for driving low-speed signals for long distances to multiple
> >> receivers without worrying about termination.
> >>
> >> Bob Perlman


Article: 48456
Subject: Re: How assingment of IOE by Quratus Ver2.1
From: "Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl>
Date: Fri, 18 Oct 2002 00:36:50 +0200
Links: << >>  << T >>  << A >>
> I'm designing LCD Controller using ALTERA Quartus Ver2.1.
> I want to assign output FF signal to IOE register by Quartus Ver2.1.
> However, I don't know how to assign using this software.

There are many ways to do this. The most standard (not the fastest) method
is as follows:

On the menu, go to Tools->Assignment Organizer, or just hit Alt-O. Then
click the "Edit specific entity & node settings for..." selection and click
the "..." button on the right side. This will get you into the Node Finder.

In the Node Finder, set the filter to "Pins: all", make sure that the
"include subentities" option is _NOT_ checked (this will save you time) and
click the "Start" button. From the resulting list on the left, select the
signals you want to change to an IOFF and click the ">" button so that the
signals are copied to the list on the right, and then the "OK" button. This
will return you to the Assignment Organizer.

The line following "Edit specific entity & node settings for..." will now
show you the signal you selected, or, if it was more than one "<multiple
signals" or something like that.

Now, click on the "+" sign in front of the line saying "Options for
Individual Nodes Only", then on "Add a new Assignment". From the list of
assignments on the right, select the option "Fast Output register" and set
it to "On". Then click "Apply" and "Ok". Then recompile and all _should_ be
OK now.

If this does not work, just give me a shout.

Best regards,


Ben






Article: 48457
Subject: Re: Proveedor de Soluciones uC/FPGA/DSP - uC/FPGA/DSP Solutions Provider
From: jaime.aranguren@ieee.org (Jaime Andres Aranguren Cardona)
Date: 17 Oct 2002 15:39:02 -0700
Links: << >>  << T >>  << A >>
Hello,

Thanks for the encouragement, Jerry. That makes feel great.

JaaC

Jerry Avins <jya@ieee.org> wrote in message news:<3DAEF3AF.4D7DE478@ieee.org>...
> Jaime Andres Aranguren Cardona wrote:
> > 
> > Cordial saludo,
> > 
>   ...
> 
> Congratulations! I wish you well. 
> 
> Jerry

Article: 48458
Subject: Re: HELP about signal integrity, PLEASE!
From: "Ben Twijnstra" <bentw@SPAM.ME.NOT.chello.nl>
Date: Fri, 18 Oct 2002 00:48:06 +0200
Links: << >>  << T >>  << A >>
Hi Itaso,

>  I would like to know if I need any terminator technology for Altera`s
> APEX 20KE I/O pins. I have read a lot about this feature for Stratix
> devices, but nothing for APEX devices. I think that the terminator
> technology will depend on the standard I/O used. For more information
> I add that I'm using LVTTL for all the pins. HELP, please!

The APEX do not have Termnator Technology or something like that.

As Falk Brunner pointed out, bouncing and ringing of signals is strongly
dependant on the slew rate. Thus, if you are worried about signal integrity,
look at Falk's equation (I'm not 100% sure where he got the figures but it
feels ok) and turn on the "Slow Slew rate" option for the I/O's that you
feel are at risk. This will add about 1.1ns to the rise and fall time (it's
not quite symmetrical) of the signal, thus reducing bounce. It does add to
your Tco as well, so make sure that you meet your timing budget for these
signals.

Best regards,



Ben




Article: 48459
Subject: Re: Why can Xilinx sw be as good as Altera's sw?
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 17 Oct 2002 19:24:25 -0400
Links: << >>  << T >>  << A >>
Neil Franklin wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> 
> > Neil Franklin wrote:
> > >
> > > > Yes, you are not an FPGA designer.  You are on the fringe and you can
> > > > use whatever you want.  But this discussion was about the viability of
> > > > open source tools and I think you will still find that they will not be
> > > > well received by the FPGA design community.
> > >
> > > For me it is, and has allways been, about making them, and those
> > > people I know who intend to use them. It you were labouring under
> > > the impression that I intended to take over the market, then you were
> > > reading my stuff wrong.
> >
> > No, but you have been saying that open source tools will become "better"
> > than X or A tools.  I don't agree that this will ever happen.
> 
> I think we need to define "better" here. You seem to define it as
> "supports newest stuff". Open source people define it as "more
> flexible, less bugs, less usage restrictions", and also an fairly
> difficult[1] to describe "feels right" that open source stuff has.
> 
> [1] one ingredient is that it is user-written and therefore simple
> "fits" the way users work better than anything that is specified by
> an market research team.

Ok, you define "better" that way then it may be better.  But I don't
know many engineer who use those metrics as their primary tests of a
tool.  Most of them want the tool to do a good job and to do it on the
parts they want to use.  


> > > > have said that they feel they have to provide support to anyone using
> > > > their chips regardless of the tools they are using.
> > >
> > > Simply point out, that it is not out tool - no support - come back
> > > if problem also happens with our official tool. Open source users
> > > understand this.
> >
> > I don't know what this means.
> 
> Translation: "we don't support you, unless you use our tools".

I think one of the problems we have is that you don't post in clear
complete sentances and thoughts.  The above "translation" is clear, but
its purpose is not.  I assume that you are saying that this is what
Xilinx would say to a open source tool user?  Xilinx people have posted
here that they feel the need to support anyone buying their chips.  If a
company wants to put 1,000,000 boards out with a Xilinx FPGA and they
are having trouble getting a bitstream to work reliably using open
source tools, Xilinx isn't going to say "tough".  Or at least this is
how I understand the postings here on similar topics by Xilinx people. 
Providing such support will be very tough for Xilinx so they will try to
avoid this situation ever happening by not supporting open source
tools.  


> > > > How could anyone make a bitstream compatible
> > > > FPGA?  Can you explain how they would get around the legal IP issues?
> > >
> > > As I said: worst case get an license, in absolute worst case by
> > > tripping up one of the existing players (if they blankly refuse). IP
> > > law can be very interesting in that respect.
> > >
> > > Also anyone with enough financial interest can actually take an patent
> > > to court and have it declared irrelevant on an whole range of issues.
> > > It takes time and cost. But if enough profit are waiting, things like
> > > that happen.
> >
> > Where do open source advocates get the financial backing???
> 
> We were not talking of open source (= software) developers here. We are
> talking about an chip (= hardware) vendors. Such tend to have money, a
> lot of it.

So how do you know that anyone will be making a clone chip anytime in
the future?  Why do you think that a company could make money by trying
to move into a "specialty" market and turning it into a "commodity"
market?  I certainly see no reason for a company to spend large sums of
money to do so.  


> > to cooperate.  But if you don't *have* IP, how will you bargan with
> > them?
> 
> Any chip company can buy in IP, until they have enough to make A&X
> listen. Just look at how VIA got round Intels P4 signalling patents by
> exactly that trick.

They can't buy it from X&A!  If X&A are using others IP, then they most
likely are paying for it already so there is no leverage.  

I have not heard that the I&V suit is settled.  Last I heard they were
still in court, so Via has gotten away with nothing.  


> > > Also you may want to take into account, that Altera managed to
> > > survive Xilinxes patents, despite starting when they Xilinx had
> > > maximal protection, and with Altera an latecomer. Any new competitor
> > > has an easier situation.
> > >
> > > And an further scenario: assume bit compatible becomes important.
> > > Either X or A is the winner in becoming the standard. How long do you
> > > think will the other of the 2 look at declining sales, until they
> > > clone? And we already know that a patent battle between them 2 ends in
> > > stalemate.
> >
> > I disagree that a newcomer *now* has an easier time of it.  Now you have
> > not only X to deal with, you have the X&A cartel.
> 
> Whose remaining patents are becoming more and more detail focussed, as
> the basic ones are running out. And so easier to circumvent by using
> an different implementation. The days when simply an LUT or an PIP was
> an new idea and patentable are over.

And it would be very difficult to use that different implementation to
make a bitstream compatible part.  

> >  They have a vested
> > interest in keeping others out.
> 
> Interest yes, but success in doing it?

So far, so good!  What happened to all the others who have tried?  


> > > The short conclusion: IP law is in no way the "no chance" you seem to
> > > regard it as. In particular when one has got enough money to run
> > > through an dedicated battle.
> >
> > Well, then show us the money :)
> 
> A: the entire sub-discussion was about an potential (= not yet the
> case, and possible never the case) situation
> 
> B: if the situation arrives, then the money can be shown. Basically
> that demonstration will point to (part of) the profit possible by cloning.

You are therefor making claims that you are now saying can not be
demonstated.  Kinda hard to draw a conclusion.  I think you greatly
under estimate the difficulty of starting such a business and over
estimate the potential rewards.  Both will keep any company out of the
market for a long time unless they produce parts that are somehow new
and don't infringe.  


> > > > You misunderstand.  The did nothing to "help break the license" other
> > > > than to use the bitstream that came from an Altera tool.
> > >
> > > And that is exactly the entire meaning of "help break the license".
> > > Offering an service that is auxillary to an crime, without any other
> > > legal use for that service. Look up "contributary infringement" if you
> > > want an interesting read. I understand the legal concept here very
> > > well, having read quite a bit on the Napster/Kazaa/etc cases and the
> > > deCSS/2600/websites cases, and the argumentation against them.
> >
> > But you make a point that has nothing to do with the discussion.  We are
> > talking about making chips.
> 
> In this sub-discussion (of about 5 subdiscussions in this thread) you
> were claiming that Altera broke Clearlogic on an FPGA patent. I was
> countering that claim.
> 
> > > You can get around an patent. Altera survived Xilinxes ones. AMD has
> > > wrung patents off of Intel, by tripping them over other stuff. Via has
> > > stopped Intel attacks by tripping them up. Ask an good IP lawyer about
> > > all the possibilities. IP law is not the clear "you lose" that you
> > > believe it to be.
> > >
> > > In fact the very name IP is an error, they are no property, but rather
> > > privileges, granted for very specific terms. And many patents do not
> > > fit those terms, and only survive because being not challenged, because
> > > fighting them is not profitable. Add an good slice of potential profit
> > > and the overturning starts.
> >
> > Who is going to go up against X and A over these patents?  Who has this
> > money?
> 
> Whoever convinces an investor or managment that there is money to be
> made in clones. And no I am not going to try an predict a company name.

And that is where we differ.  There is very little money in making a
"clone" and thereby changing the market to a commodity.  All the
manufacturers would suffer from this.  


> > > > Yes, but that is not an FPGA is it?  The point is that Altera felt a
> > > > threat and used their IP to shut them down.
> > >
> > > The point is that they only just managed. That IP is not the surefire
> > > "end of competition" you seem to regard it as.
> >
> > You say they "just managed" but Clearpoint was not making FPGAs were
> > they?  So how is their case relevant?
> 
> It is relevant to show you that FPGA patents are not the all-powerfull
> things you presented them as. Again here: annother sub-discussion.
> This thread has wandered quite far, even within single posts.

And it failed to show that.  


> > > AFAIK ARMs patent claim was not that strong, they had luck that their
> > > opponent was weak or possibly simply not interested (better stuff to
> > > do than fight[1]) and caved in. MIPS had a stronger case against a
> > > cloner, but their patent is also near/in EOL.
> >
> > If the ARM case is not strong, then why does everyone including the
> > behemoth Intel license rather than "break" the patents?
> 
> Intel did not just re-implement the ARM instruction set, they actually
> took over ARM/DEC chip design internals and actual design code (and a
> few employees AFAIK). That translated into faster to market for them.
> That is what the license was for, and paid from.

So in the Intel case it is a good business decision to license the
technology from ARM rather than to try to fight them.  In the case of
Xilinx it is better to fight them than to license the technology or to
buy the chips?  Why?  I think there is little difference.  

So what about all the dozens of other licensees of the ARM design? 
Obviously it is not that difficult a design to produce since a college
student produced one.  None of the licensees have tried to fight ARM
over the patent issue rather than pay the license.  And then there are
dozens if not hundreds of competing CPUs that don't infringe the
patents.  You like making comparisons between CPUs and FPGAs.  Why is it
so different in this context?  Why would *any* company try to build
compatible FPGAs that infringe patents rather than build one that is
different and does not?

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 48460
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Fri, 18 Oct 2002 00:26:54 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote
> Bob, I agree, but being a (good?) applications engineer,
> I try to find a work-around:
> How's about an old-fashioned 100 pF capacitor to ground,
> right at the FPGA pin. That should smoothe out the edge.
> Not elegant, clutters up the pc-board, but it should work,
> and anybody can do it today.
> And the benefits of low ground-bounce, EMI, crosstalk etc.
> still apply.

Peter - since you put your head above the parapet...

Would the tiny Philips/Phicomp/... RCB210 resistor/capacitor
networks do the job, and be easier to route?  The smallest
values in my catalog seem to be 22pF/47R.  100pF/47R and
100pF/82R are also listed.  Case size is 1608, 10 terminals.




Article: 48461
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 17 Oct 2002 17:03:41 -0700
Links: << >>  << T >>  << A >>
Depends on the configuration. A series resistor of 100 Ohm or
thereabouts would be acceptable, but the C must be to ground.
Best would be R to the FPGA, C to ground, common point as output.
Less good, but probably acceptable would be RC in series to ground,
FPGA pin as output.
RC in parallel would obviously not work.
The idea is that at 2 mA the FPGA output impedance is close to a kilohm.

Petert Alfke

Tim wrote:

> Peter Alfke wrote
> > Bob, I agree, but being a (good?) applications engineer,
> > I try to find a work-around:
> > How's about an old-fashioned 100 pF capacitor to ground,
> > right at the FPGA pin. That should smoothe out the edge.
> > Not elegant, clutters up the pc-board, but it should work,
> > and anybody can do it today.
> > And the benefits of low ground-bounce, EMI, crosstalk etc.
> > still apply.
>
> Peter - since you put your head above the parapet...
>
> Would the tiny Philips/Phicomp/... RCB210 resistor/capacitor
> networks do the job, and be easier to route?  The smallest
> values in my catalog seem to be 22pF/47R.  100pF/47R and
> 100pF/82R are also listed.  Case size is 1608, 10 terminals.


Article: 48462
Subject: Re: ps/2 keyboard FSM code simplification....
From: "MikeJ" <pacman@fpgaarcade.com>
Date: Fri, 18 Oct 2002 01:10:22 +0100
Links: << >>  << T >>  << A >>
at www.fpgaarcade.com look in the space invaders code top level by Daniel W,
he has a small & neat ps2 decoder (vhdl)
/MikeJ
"Leon de Boer" <ldeboer@attglobal.net> wrote in message
news:3daeeeda_3@news1.prserv.net...
> Any suggestions how to make this crappy PS/2 decoder state machine better
> appreciated.
>
> DEFINITIONS OF SIGNALS YOU MIGHT NEED TO KNOW
>
> P15, P16 are standard input pins of FPGA
> in12Mhz is obviously a 12Mhz clock input pin
> Reset is active low input pin
>
> --[ KEYBOARD STATE MACHINE CONTROL SIGNALS ]--
> TYPE key_states is (s0, s1, s2, s3, s4, s5, s6, s7);
> SIGNAL keystate: key_states;
>
> --[ KEYBOARD INPUT CONTROL SIGNALS ]--
> SIGNAL kbparity: STD_LOGIC;
> SIGNAL kbinclock: STD_LOGIC;
> SIGNAL kbindata: STD_LOGIC;
> SIGNAL kbbitcount: INTEGER RANGE 0 to 7;
> SIGNAL kbwatchreset: STD_LOGIC;
> SIGNAL kbwatchdog: INTEGER RANGE 0 TO 32767;
>
> --[ KEYBOARD IN FIFO SIGNALS ]--
> SIGNAL keyhead: INTEGER RANGE 0 to (keybufsize-1);
> TYPE KeyMem is ARRAY (0 to keybufsize-1) of STD_LOGIC_VECTOR(7 downto 0);
> SIGNAL keydata: keymem;
> SIGNAL keyintemp: STD_LOGIC_VECTOR (7 downto 0);
>
>
> THE CRAPPY CODE
>
> --------------------------------------------------------------------------
-
> -- KEYBOARD HANDLER PROCESS
> --------------------------------------------------------------------------
-
> keyboard_handler: PROCESS (reset,  in12mhz, keystate, keyhead, p15, p16,
> kbinclock, kbindata, keyintemp)
> BEGIN
>     IF (reset = '0') THEN                      -- reset is active
>    OR (kbwatchreset = '0') THEN        -- watchdog has kicked in
>        keystate <= s0;                             -- start on state 0
>        IF (reset = '0') THEN                    -- only on reset
>            keyhead <= 0;                           -- zero keyboard head
>        END IF;
>        kbwatchreset <= '1';                     -- watch dog reset high
>        kbwatchdog <= 0;                        -- zero watchdog count
>        kbinclock <= '1';                           -- set kbinclock to '1'
>        kbindata <= '1';                            -- set kbindata to '1'
>    ELSIF rising_edge(in12mhz) THEN  -- clock signal edge
>        kbinclock <= p15;                        -- latch keyboard clock
>        kbindata <= p16;                         -- latch keyboard data
>        kbwatchreset <= '1';                     -- preset watchdog reset
> high
>       IF (kbwatchdog = 32000) THEN  -- watch dog has timed out
>          kbwatchreset <= '1';                  -- set watchdog reset
signal
>       ELSE
>           IF (keystate = s0) THEN          -- in state s0 it is stable
>              kbwatchdog <= 0;                 -- watchdog never counts
>           ELSE
>              kbwatchdog <= kbwatchdog + 1;  -- inc watchdog count
>           END IF;
>       END IF;
>       CASE keystate IS
>          WHEN s0 =>                            -- find clock edge low
>              keystate <= s0;                      -- preset stay on this
> state
>              IF (kbinclock = '0') THEN    -- falling clock edge
>                 keystate <= s1;                   -- move to next state
>              END IF;
>          WHEN s1 =>                            -- find clock edge high
>              keystate <= s1;                      -- preset stay on this
> state
>              kbparity <= '0';                      -- clear parity check
>              kbbitcount <= 0;                    -- zero bit count
>              IF (kbinclock = '1') THEN     -- clock is now high
>                 keystate <= s0;                   -- preset error back to
s0
>                 IF (kbindata = '0') THEN   -- start bit was found
>                    keystate <= s2;                -- move to next state
>                 END IF;
>             END IF;
>         WHEN s2 =>                             -- find clock edge low
>            keystate <= s2;                        -- preset stay on this
> state
>            IF (kbinclock = '0') THEN       -- falling clock edge
>                keystate <= s3;                    -- move to next state
>            END IF;
>         WHEN s3 =>                             -- find clock edge high
>             keystate <= s3;                       -- preset stay on this
> state
>             IF (kbinclock = '1') THEN      -- clock has gone high
>                keyintemp(kbbitcount) <= kbindata;  -- hold data bit
>                kbparity <= kbparity XOR kbindata; -- add to parity
>                IF (kbbitcount = 7) THEN   -- 8 bits loaded now
>                    keystate <= s4;                -- move to next state
>                ELSE
>                    kbbitcount <= kbbitcount + 1;   -- inc bit in count
>                    keystate <= s2;                -- back to wait clock
low
>                END IF;
>            END IF;
>       WHEN s4 =>                               -- find clock edge low
>           keystate <= s4;                         -- preset stay on this
> state
>           IF (kbinclock = '0') THEN        -- falling clock edge
>              keystate <= s5;                      -- move to next state
>           END IF;
>      WHEN s5 =>                                -- find clock edge high
>           keystate <= s5;                         -- preset stay on this
> state
>           IF (kbinclock = '1') THEN        -- clock has gone high
>              kbparity <= kbparity XOR kbindata;  -- create parity check
>              keystate <= s6;                      -- move to next state
>           END IF;
>      WHEN s6 =>                               -- find clock edge low
>           keystate <= s6;                        -- preset stay on this
> state
>           IF (kbinclock = '0') THEN       -- falling clock edge
>              keystate <= s7;                     -- move to next state
>          END IF;
>      WHEN s7 =>                               -- find clock edge high
>          keystate <= s7;                          -- preset stay on this
> state
>          keydata(keyhead) <= keyintemp;  -- store data to key buffer
>          IF (kbinclock = '1') THEN        -- clock has gone high
>             IF (kbparity = '1') THEN       -- parity correct
>                IF (keyhead=(keybufsize-1)) THEN -- at buffer end
>                   keyhead <= 0;                  -- roll back to buffer
> start
>                ELSE
>                   keyhead <= keyhead + 1; -- advance buffer position
>                END IF;
>            END IF;
>            keystate <= s0;                       -- move to start state
>         END IF;
>      END CASE;
>    END IF;
> END PROCESS keyboard_handler;
>
>
>
>



Article: 48463
Subject: Re: Hobbyist FPGA
From: "MikeJ" <pacman@fpgaarcade.com>
Date: Fri, 18 Oct 2002 01:12:51 +0100
Links: << >>  << T >>  << A >>
More importantly you can play pacman and space invaders in a 300e (ok,
external program rom required) !
MikeJ

"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:aomr61$1esa$1@agate.berkeley.edu...
> In article <aomqje$nr2og$2@ID-84877.news.dfncis.de>,
> Falk Brunner <Falk.Brunner@gmx.de> wrote:
> >Nowadays, Iwouldnt recommend anythink below 200k. Get a nice
Spartan-II(E)
> >with 200 or even 300k gates.
> >They are cheap.
> >
> >www.nuhorizons.com        (200k)
> >www.burched.com            (300k)
> >
> >The tools from Xilinx are free. Go for Webpack.
>
> Not only that, but consider the following:
>
> In a Spartan 2-100, you can do 1.3 Gbps AES encryption.  In a $10
> part.  About 1.7 Gbps in an E.
>
> In a Spartan 2-200, you can probably build a 70-80MHz, 2 thread, MIPS
> or SPARC compatable processor.  Probably >100 MHz in an E.
>
> In a Virtex 400, you can dump a SYNTHESIZED, GPL'ed SPARC core.
>
> Those cheap parts (Spartan II/IIE) are big and powerful, as well as
> cheap.
>
> (I not very wistfully remember doing a sample-based MIDI synthesizer
> in a 4005 as a class project.  It ALMOST fit in a 4003.)
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu



Article: 48464
Subject: Re: Quartus design question
From: kayrock66@yahoo.com (Jay)
Date: 17 Oct 2002 17:34:27 -0700
Links: << >>  << T >>  << A >>
I commend your use of x's for the sake of readable code but
unfortunately you're pushing the limits of the free-bee synthesizer
packaged with Quartus.  What you desire will work fine with the more
seasoned synthesizers but if you're targeting the built in Quartus
synthesizer your code better look like a section from Verilog 101 and
run a gate lavel sim following to verify correct translation.

Regards

"Brian Guralnick" <innerdimension@videotron.ca> wrote in message news:<EnMp9.9726$dE6.209743@weber.videotron.net>...
> The 'x' was a habit gained from the AHDL language.  When I started with verilog a few months back, I figured it might work.  In
> Quartus2.0 and earlier, it did work.  It was very handy in creating a bus decoder with different pages.
> 
> eg:
> 
> parameter adr_range = "16b'1x000000xxxxxxxx'";
> OLD:
> ......
> if (adr_in == adr_range) ena <= 1;
>         else ena <= 0;
> ......
> 
> new:
> ......
> if ( (adr_in[15] == 1) && (adr_in[13:8] == 0) ) ena <= 1;
> 
>         else ena <= 0;
> ......
> 
> The problem here is that I can not use the parameter, unless there is a proper way to do the compare within Verilog.
> 
> 
> 
> ____________
> Brian Guralnick
> innerdimension@hotmail.com
> (514) 624-4003
> 
> 
> "Blackie Beard" <BlackBeard@FearlessImmortalWretch.com> wrote in message news:YbLp9.3453$qb.2015@nwrddc01.gnilink.net...
> > I'm not convinced that Verilog will let you use 'x' as a don't care.
> > I do know that 'x' from a simulation result found on a wire is not
> > a don't care, but an error (no signal driven, or contention)
> >
> >
> > "Brian Guralnick" <innerdimension@videotron.ca> wrote in message
> > news:KSKp9.9423$dE6.195978@weber.videotron.net...
> > > So, if I understand you correctly, you want Quartus to see the results
>  coming in from externally connected ram & you want that ram
> > > to be functional.
> > >
> > > It would seem that the contents of the Verilog SRAM model should behave as
>  your SRam.  Though I'm getting fairly good at verilog
> > > programming, I still have to learn how to use the simulation models.  If
>  you contacted Altera, you'll probably get the answer to do
> > > everything in verilog & use Leonardo Spectrum for simulation.
> > >
> > >
> > > My all in Quartus solution would be something like this:
> > >
> > > Make a second dummy Quartus project which emulates your SRAM using
>  standard RAM_DQ.  Create a symbol for that project.  Now, in your
> > > main project's simulation block diagram, place the SRAM projects
> > >
> > > I have successfully done this for 8 megabit sram.  It worked fine for
>  functional simulation, but, in timing mode, everything messed
> > > up.
> > >
> > >
> > > Warning: If you use Quartus to compile your *.v files, changing from Q2.0
>  to Q2.1 can mess up a whole lot of things...
> > > My recent finds are:
> > > --->   if (adr[7:0] == 8'b1000xxxx') begin...
> > > The don't cares 'x' no longer work, and they don't work even with the
>  '===' when they should, Quartus2.1 will simplify out this 'if'
> > > block to do nothing.
> > > --->   notadr[7:0] <= !adr[7:0];
> > > This also used to work, now, it also does something funny.
> > >
> > > ____________
> > > Brian Guralnick
> > > innerdimension@hotmail.com
> > > (514) 624-4003
> > >
> > >
> > > "Paul Baxter" <pauljnospambaxter@hotnospammail.com> wrote in message
>  news:3da72d0e$0$1291$cc9e4d1f@news.dial.pipex.com...
> > > >
> > > > "Engineer" <victor1357@hotmail.com> wrote in message
> > > > news:b041a362.0210111058.742f72e0@posting.google.com...
> > > > > Hi all,
> > > > > I am trying to develop a SRAM controller using Quartus 2.1 from
> > > > > Altera. The design contains a controller and also a Verilog file with
> > > > > SRAM model (which I need for simulation and other kinds of
> > > > > verifications).
> > > > > The question is: how to separate controller files from SRAM files in a
> > > > > design, so that Quartus doesn't put SRAM together with controller on a
> > > > > chip.
> > > > > Unfortunately, I was not able to achieve this so far.
> > > > > Any comments appreciated.
> > > > > ========================
> > > > > Victor Ober
> > > > > Transtech
> > > >
> > > > The big problem you'll probably run into is that Quartus is a
>  synthesis-only
> > > > simulator so quite often models of RAMs etc simply do not work in
>  Quartus.
> > > >
> > > > What you're describing is having the main design synthesised and placed
>  to
> > > > provide a full timing-correct 'model of your device under test. A
>  simulation
> > > > testbench then models the connections of your DUT with the SRAM for
> > > > simulation.
> > > >
> > > > Altera does provide a limited edition Modelsim license in the full
>  version
> > > > which CAN do this sort of thing. Personally I found ActiveHDL a far
>  easier
> > > > and comprehensive simulator but this unfortunately costs more money
>  (similar
> > > > to a purchase of the full Modelsim license)
> > > >
> > > > I really would recommend downloading the ActiveHDL trial (www.aldec.com)
>  as
> > > > it also has comprehensive help files explain just such a setup.
> > > >
> > > > Good luck
> > > >
> > > > Paul Baxter
> > > >
> > > >
> > >
> > >
> >
> >

Article: 48465
Subject: Re: Xilinx microblaze vs. picoblaze
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 18 Oct 2002 00:37:07 -0000
Links: << >>  << T >>  << A >>
>I have not heard of this threading concept before, but it makes sense at
>a hardware level.  I am not sure I understand the software
>implications.  It seems to me that the multiple instruction streams must
>be completely independant and infact, you must have a separate PC for
>each stream, no?  So how do you run something like this?  I guess there
>must be instructions for starting and stopping each separate thread in
>the processor.  Or do all the threads start following reset???  How
>would the OS manage that?  

It's just like SMP.  The hardware is time interleaved rather than replicated.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 48466
Subject: Re: xilinx: VirtexII in a pqfp208 or pqfp240 ?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Fri, 18 Oct 2002 02:02:56 +0100
Links: << >>  << T >>  << A >>
Peter Alfke wrote
> Depends on the configuration. A series resistor of 100 Ohm or
> thereabouts would be acceptable, but the C must be to ground.
> Best would be R to the FPGA, C to ground, common point as output.
> Less good, but probably acceptable would be RC in series to ground,
> FPGA pin as output.
> RC in parallel would obviously not work.
> The idea is that at 2 mA the FPGA output impedance is close to a kilohm.
>

<snip>

> > Would the tiny Philips/Phicomp/... RCB210 resistor/capacitor
> > networks do the job, and be easier to route?  The smallest
> > values in my catalog seem to be 22pF/47R.  100pF/47R and
> > 100pF/82R are also listed.  Case size is 1608, 10 terminals.
>

That is the way it works.  The Rs look like a standard 8-pin RP,
with caps in series from the output terminals to common ground
terminals on the short edges.




Article: 48467
Subject: Re: Xilinx microblaze vs. picoblaze
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 17 Oct 2002 21:43:11 -0400
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> >I have not heard of this threading concept before, but it makes sense at
> >a hardware level.  I am not sure I understand the software
> >implications.  It seems to me that the multiple instruction streams must
> >be completely independant and infact, you must have a separate PC for
> >each stream, no?  So how do you run something like this?  I guess there
> >must be instructions for starting and stopping each separate thread in
> >the processor.  Or do all the threads start following reset???  How
> >would the OS manage that?
> 
> It's just like SMP.  The hardware is time interleaved rather than replicated.

Yes, I understand that.  But when you replicate the hardware, you
replicate *all* of the hardware.  I have not heard anyone say that there
are multiple copies of the program counter (PC).  If you are working off
one PC how do you switch between the threads on a clock cycle basis? 
Additionally, how do you start up a thread?  When this multiple thread
CPU starts following reset, each of the threads will need to be running
*something*.  How is that managed?  Do they all boot the BIOS or
whatever startup code you have?  

-- 

Rick "rickman" 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      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 48468
Subject: using the JTAG port for debugging
From: "Jamie Morken" <jmorken@shaw.ca>
Date: Fri, 18 Oct 2002 02:08:16 GMT
Links: << >>  << T >>  << A >>
Hi,

Is it possible to use the JTAG port on an FPGA (Spartan IIE) for debugging
with Xilinx Webpack?
Is the cable expensive?  I would like to use the JTAG port to act as a logic
analyzer on the FPGA I/O's.
What is the peak frequency the JTAG port would be useful for this?

cheers,
Jamie Morken



Article: 48469
Subject: Size of configuration bitstream for xcv50 (xilinx)
From: meghnaag7@hotmail.com (Meg)
Date: 17 Oct 2002 19:14:40 -0700
Links: << >>  << T >>  << A >>
hi
i am new to FPGAs. i want to run compression algorithms on virtex
xcv50 configuration file. i have consulted the xilinx app. notes as
well as other few websites. The xilinx website says the configuration
bits needed are 559,200bits (= 69,900 bytes) but at
fpgaconfigurator.com, it is mentioned tht 559,232 bits are needed. The
bit file generated by Xilinx tools has the size 69,967 bytes which is
67 bytes more than specified by xilinx. I am really confused about
what's going on ??

moeover from what i understand, xcv50 needs 15,876 32-bit words for
CLBs, 780*2 for ram and 39 words for issuing commands. The sum of all
these is less than the number of configuration bits required
(559,232), So, how exactly is this figure calculated ??

Meghna

Article: 48470
Subject: Locating IOBs with shared routing resources in VirtexII.
From: Brijesh <brijesh_spamNot@vt.edu>
Date: Fri, 18 Oct 2002 02:48:38 GMT
Links: << >>  << T >>  << A >>
The xilinx app note: xapp253 ( DDR SDRAM controller using Virtex II) talks about using HEX lines for low skew routing. Here is the snippet from the app note.

"As described in the Virtex-II data sheet, each I/O tile contains four IOBs that share a switchmatrix.IOB PAD4 is the top IOB in a I/O tile. In order for the DQS to access a local low-skew clock line, DQS must be placed on the top IOB, PAD4 in the I/O tile. If IOB PAD4 is not available in a tile, or is unbonded, then it cannot be used to place the DQS signal.

Placing the DQS signal in PAD4 gives access to a local clock line which is a HEX line spanning
five rows above the chosen I/O tile and six rows below the chosen I/O tile. The data (DQ) pads
should be placed in the bonded IOBs available within these specific rows."

Question is 
1) How does one locate the "IOB pad4: top IOB of an I/O tile" ?
2) We know that 4 adjacent IOB's share the routing resources. How do we know which four?

Virtex II data sheets and hand book mention this but do not give any info on how to locate them .
So where will I find this info. 

Thanks
Brijesh
brijesh at vt dot edu
 


Article: 48471
Subject: Re: Intel ARM 'XScale' cores as IP blocks that can be synthesized into an FPGA/ASIC?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 17 Oct 2002 20:18:02 -0700
Links: << >>  << T >>  << A >>
Christopher Cole <cole@scoob.coledd.com> writes:
> Actually, XScale is Intel's own IP.  Intel created the XScale core via
> clean-room approach, licensing only the instruction set from ARM Ltd.
> The Intel StrongARM processor, on the other hand, uses an ARM core 
> developed by ARM Ltd.

Actually the StrongARM core was designed by the late, lamented Digital
Equipment Corporation (DEC).

Article: 48472
Subject: HELP please! creating FPGA for first time
From: k_guichard@hotmail.com (Kyle Guichard)
Date: 17 Oct 2002 20:49:46 -0700
Links: << >>  << T >>  << A >>
I am a student at SJSU working on my senior project. For this, I will
be creating an FPGA using Xilinx software, but I am really overwhelmed
with the ammount of information on how I can actually do this.

Can anyone direct me to some good documentation on creating FPGA's
when I have the verilog/VHDL code?


thanks!
kyle

Article: 48473
Subject: Re: Xilinx microblaze vs. picoblaze
From: Ray Andraka <ray@andraka.com>
Date: Fri, 18 Oct 2002 04:36:11 GMT
Links: << >>  << T >>  << A >>
The PC just needs to have more than one register in its feedback.  The SRL16's are
great for this.  We do this type of thing all the time with counters in our designs
so that one increment logic and an SRL 16 make up a set of time multiplexed
counters all on a common path.  The trick is to be careful that all the loops are
pipelined to the correct level.  You can reset one counter without resetting the
rest, branch on each one independently etc.

rickman wrote:

> Yes, I understand that.  But when you replicate the hardware, you
> replicate *all* of the hardware.  I have not heard anyone say that there
> are multiple copies of the program counter (PC).  If you are working off
> one PC how do you switch between the threads on a clock cycle basis?
> Additionally, how do you start up a thread?  When this multiple thread
> CPU starts following reset, each of the threads will need to be running
> *something*.  How is that managed?  Do they all boot the BIOS or
> whatever startup code you have?
>
> --
>
> Rick "rickman" 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      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 48474
Subject: Re: Locating IOBs with shared routing resources in VirtexII.
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Fri, 18 Oct 2002 05:08:18 GMT
Links: << >>  << T >>  << A >>
Brijesh wrote:
 
> The xilinx app note: xapp253 ( DDR SDRAM controller using Virtex II) talks about using HEX lines for low skew routing. Here is the snippet from the app note.
> 
> "As described in the Virtex-II data sheet, each I/O tile contains four IOBs that share a switchmatrix.IOB PAD4 is the top IOB in a I/O tile. In order for the DQS to access a local low-skew clock line, DQS must be placed on the top IOB, PAD4 in the I/O tile. If IOB PAD4 is not available in a tile, or is unbonded, then it cannot be used to place the DQS signal.
> 
> Placing the DQS signal in PAD4 gives access to a local clock line which is a HEX line spanning
> five rows above the chosen I/O tile and six rows below the chosen I/O tile. The data (DQ) pads
> should be placed in the bonded IOBs available within these specific rows."
> 
> Question is
> 1) How does one locate the "IOB pad4: top IOB of an I/O tile" ?

FPGA Editor.  The app note gives information on how to use it to find
the subset of pads that can be DQS pins


> 2) We know that 4 adjacent IOB's share the routing resources.

Word of warning.  Remember that some IOBs are unbonded, so there may be
only two bonded IOBs that share routing resources.  And remember that
the routing of clocks for DDR is shared between pairs of IOBs even more
closely.  These pairs are easy to identify: the name in the pinout
tables shows pairs, for example:  IO_L06N_0 IO_L06P_0.


>  How do we know which four?

FPGA Editor.


> Virtex II data sheets and hand book mention this but do not give any info on how to locate them .
> So where will I find this info.

If you find a better source, please post it.


-- 
Phil Hays



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