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

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 22700

Article: 22700
Subject: Re: Help with macrocell , explain it to me
From: rob_dickinson@my-deja.com
Date: Thu, 18 May 2000 11:57:20 GMT
Links: << >>  << T >>  << A >>
In article <fUNU4.25973$sB3.8788@news.indigo.ie>,
  "Eircom" <keith@suparule.com> wrote:
> Can some one explain
>
> What is a macrocell
> It's use
>
> keith@suparule.com
>
Please try to help yourself.  You have presumably started looking into
a pld of some description and found this reference.  Read its
description in a datasheet and if you don't understand because its
badly written or not in your first language we will all be happy to
help.

Rob


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 22701
Subject: [Final Ann] New FPGA Proto Kits Sale Extended for a short time
From: "Tony Burch" <tony@BurchED.com.au>
Date: Thu, 18 May 2000 22:46:24 +1000
Links: << >>  << T >>  << A >>
New, low cost, no fuss FPGA prototyping kits.
Burch Electronic Designs
www.BurchED.com.au

The massive 20% off opening sale has been
extended for just a few more days!
Prices absolutely, positively have
to go back up on Friday 26th May 2000!
At this price, grab a couple for your
lab before the sale ends!

We are now listed at OptiMagic Programmable
Logic Jumpstation (thanks to Steve Knapp).
Check out and compare at:
http://www.optimagic.com/boards.html

************

Announcing new, low cost, no fuss
FPGA prototyping kits -
real FPGA tools for real-world
prototypes.

These are the lowest cost, easiest to use
FPGA prototyping kits on the market!

Your favourite FPGA vendor is supported -
Xilinx, Altera, Atmel, Lucent and Actel.

Strength in simplicity:
- FPGA (5K to 10K gates) on a board
- Easy connection - FPGA pin numbers
   labelled on both sides of the board
- Prototyping area - add what you want
- Canned crystal oscillator module plus
   other components included
- Configuration download pod board included
- PC parallel port interface capability
- Low cost
- Easy!

****************************************
OPENING SALE - 20% off the normal price!
****************************************

...An excellent time to grab a bunch of
these for your lab, or maybe one for your
student project.

Pictures, specs, resources and online shop at
Burch Electronic Designs:
www.BurchED.com.au


P.S.

Lots and lots of uses. Here's some:
- Prototype a module of your design for
   demonstration purposes, or to increase
   confidence in the module for a final
   target design.
- Build them into one-off systems or special
   purpose test equipment.
- Have a couple on hand for when you need to try
   out that circuit quickly (generally happens
   at midnight :) ).
- Student projects (digital logic design, computer
   architecture, DSP, telecomms etc. etc.).



Article: 22702
Subject: verilog modules into viewlogic designs
From: maespin <maespin@romulus.ncsc.mil>
Date: Thu, 18 May 2000 10:33:35 -0400
Links: << >>  << T >>  << A >>
What is the best (easiest/fastest/most efficient) way to get verilog
modules into a xilinx fpga design which was created using viewlogic's
viewdraw schematic capture tool?

Thanks,
Mark





Article: 22703
Subject: tag programming software
From: Trent Worthington <none@all.not>
Date: Thu, 18 May 2000 12:50:19 -0400
Links: << >>  << T >>  << A >>
Hello,
We're looking for software to program jtag devices. Our requirements
are that it be ms-dos based. Currently the only devices we need
support for are AMD/Vantis M4-256/128 and Xilinx 9572. Are there any
other programs besides JTAGPROG from http://www.jtag.com/ , or are
they the only game in town?

Thanks for any replies.

Best regards,
Trent
Article: 22704
Subject: Apex LVDS
From: timjeno@visto.com (Tim )
Date: Thu, 18 May 2000 18:27:37 GMT
Links: << >>  << T >>  << A >>
	I'm just curious.  Has anyone used the LVDS lines in Altera's
20KxxE Apex parts?  Actually any experiences with the devices at all
would be greatly appreciated.


         Thanks!

	Tim.

Article: 22705
Subject: Re: Q: Creating custom flip-flops in Altera MAX+Plus II
From: Steve Dewey <steve@s-dewey123.demon.co.uk>
Date: Thu, 18 May 2000 21:59:57 +0100
Links: << >>  << T >>  << A >>
In article <392216F8.78E9786D@earthlink.net>, Ashok Mahadevan
<ashokm1@earthlink.net> writes
>Hello,
>
>   I am a *very* new user to this FPGA stuff and I am using the
>schematic capture feature in Altera MAX+Plus II 9.6 Baseline for
>my design and have the following questions:
>
<<snip>>

Try looking at what you can do in AHDL (Altera Hardware Description
Language). Most of the benefits of text input (parameterisation,
conditional & repetitive compilation) without the difficulty of VHDL.

Look at http:\\www.freecore.com for some very good tutorials on this.


-- 
Steve Dewey
Article: 22706
Subject: Re: Propogation Delay
From: Douglas Armstrong <site@typhoon.xnet.com>
Date: 18 May 2000 21:03:14 GMT
Links: << >>  << T >>  << A >>
thanks for the verification.  one thing, though, is there any
specification for the time the pad begins switching versus when it hits
1.4v (as the datasheet gives for LVTTL).  thanks again!

--
douglas armstrong
Spanuza Research

Marc K. <marck@omneon.com> wrote:
: Douglas,

: Tiockp is the relevant time for outputs clocked in the IOB. It's the time
: from clock edge at the IOB K pin to output pad valid, but you do need to
: take the adjustments into account for drive strength, slew rate, and I/O
: type.

: Tioop is for outputs which are not clocked in the IOB. It's the time from
: the IOB O pin to output pad valid, but you'd need to add the delay getting
: to the IOB O pin, which includes routing delays and CLB delays.

: Pin-to-pin output parameters are, paraphrased, "what's the delay from the
: clock input pad to an output pad whose IOB is clocked?" If you use a DLL,
: the internal clock net is delayed 0ns (that's zero ns) from the input clock
: pad, so the delay from the clock pad is the same as the delay from the
: internal clock net, i.e. Tiockp. (Okay, purists, the former is 0.2ns greater
: than the latter, worst case, which is probably due to the delay through the
: IBUFG.) If you don't use a DLL, there's an additional delay from the clock
: pad through a global clock buffer to the internal clock net--the DLL is
: useful because it compensates for this delay.

: If you're clocking your outputs at the IOBs and you're using a DLL, I think
: the Tickofdll is the relevant parameter, with adjustments. If you're not
: using a DLL, then use Tickof.

: If you're not clocking your outputs, you'll need to implement your design to
: get the correct timing, which the timing analyzer provides (you won't need
: to know or care about Tioop). But that's rather risky, because routing
: delays can easily dwarf the 3-5ns Tickof, and a preliminary design which
: shows promising timing could turn into a final design with bad timing.

: The safest approach, if you can justify it, is to assume you can't use a
: DLL, design with Tickof, and then go ahead and use the DLL.

:         Marc
Article: 22707
Subject: Re: Propogation Delay
From: "Marc K." <marck@omneon.com>
Date: Thu, 18 May 2000 22:03:39 GMT
Links: << >>  << T >>  << A >>
> thanks for the verification.  one thing, though, is there any
> specification for the time the pad begins switching versus when it hits
> 1.4v (as the datasheet gives for LVTTL).  thanks again!
>

Douglas,

    That's a toughie, even for somebody involved with the design of the
chips, and I am not affiliated with Xilinx, let alone one of the Virtex chip
designers.

    I can say this: the best you can absolutely rely on is that the delay to
1.4V will fall between the minumum and the maximum for the conditions
(device type and speed, and output slew and drive strength), and that's
quite a spread. The Xilinx datasheets don't differentiate between the slew
of or delay to rising and falling edges, which are probably different.
Perhaps the IBIS models could give you a better idea.

    If it's truly important to know how early or how late an output *could*
start changing, worst case, I'd look at the equation associated with Table
14 on page 32 of the Virtex v2.1 specification, or the corresponding one for
Virtex-E. The final term implies a slew rate that is constant and depends on
output loading. You would need to determine the worst case minimum/maximum
clock to output delays (for example 1.0ns/3.6ns for Tickofdll of an XCV50,
fast slew, 12ma drive, with DLL) and then use that last term (slew rate) of
the above-mentioned equation to determine how much earlier the output would
have started switching in order for it to reach 1.4V at the specified time,
taking into account the adjustments for fast/slow slew rate and the drive
strength.

    Personally, unless you're trying to do something more than communicate
with ordinary digital logic, you shouldn't even worry about all this. Assume
the minimum and maximum  clock to output delays are the minimum and maximum
for Tickof or Tickofdll, as appropriate, for your device type, output slew
rate, and output drive strength. Then make sure that minimum delay meets the
hold time requirement of the external devices, and the maximum delay meets
the setup time requirement.

    Okay, I didn't answer your question, but I'm not sure there is a correct
answer.


        Marc



Article: 22708
Subject: Re: CLKing external RAM from FPGA (Virtex E)
From: Douglas Armstrong <site@typhoon.xnet.com>
Date: 18 May 2000 22:49:06 GMT
Links: << >>  << T >>  << A >>
So is it better to have the DLL on the FPGA drive the clocks of components
or to have a traditional clock multiplier with multiple outputs drive them
and make sure there is no clok skew?

We have a lot of parts to clock, SRAM, SDRAM, PCI, etc..  which approach
is better?  We're using non -E parts which means only 4 DLLs.  Now, the
system clock should drive one DLL directly (with feedback to itself) for
the internal logic.  So the same IBUFG input from the global clock pin
system clock can safely be split to multiple DLLs which drive normal OBUFs
(not BUFGs)?  Should each DLL drive multiple OBUFs to go to each component
with equal length traces or can it only drive one OBUF which has to then
be split with an outside part to drive each component.

Also, what are the PCB layout concerns for the feedback pin?  I'm assuming
it needs a IBUFG pin.  And that it should be routed with an equal length
as the traces going to th eother components.  Where is it best to split
the trace?  does it matter much?  But I have hesitations of one OBUF
driving the clock of, say, three PCI components and the feedback pin..

Thanks in advance!

Marc K. <marck@omneon.com> wrote:
: Tom,

: Here's another idea, if you've locked the output clocks and they're
: impossible to route with low enough skew, but it will take two global clocks
: and two BUFGPs and two DLLs.
: Take your reference clock and feed it to the first DLL's input. This DLL
: drives a global clock through a BUFGP, so the BUFGP output must feed back to
: the DLL. Use this clock for only one thing: driving the 4 (or more, possibly
: many more) output clocks. You'll need a special circuit to make sure the
: output clocks are all closely phased. I use two flops, one clocked on the
: positive edge, one clocked on the negative edge, arranged as a 2-bit gray
: counter (D1 <= !Q0, D0 <= Q1), and take Q0 ^ Q1 (actually, I used Q0 XNOR
: Q1) out to the IOB O pin directly. You'll need one instance of this clock
: circuit for every output pin, but if you place the flops and the XOR LUT
: into a single CLB (two slices, since you're using two different clock edges)
: right next to the output pin and make sure routing from the flops to the LUT
: to the IOB O pin is controlled (via constraints or manual routing) you
: should be able to get better than +-500ps skew among all the output clocks.
: As I said, you can have many more than 4 of them, and they can be
: distributed across the chip. The second DLL is used as your primary internal
: clock. Take one of your clock outputs, route it back to the second DLL, use
: a BUFGP with it. That's your clock for all internal logic. Again, since
: you're using a BUFGP with the DLL you'll need to feed back this second
: BUFGP's output to this second DLL. This clock will be phased to the output
: clocks, so you can use it to drive data out and bring it back in. You will
: add two DLL's worth of jitter to this clock, though.

: One other thing: you'll probably want to make sure the first DLL has 50%
: duty cycle compensation turned on.

: Good luck,

:         Marc


Article: 22709
Subject: Re: CLKing external RAM from FPGA (Virtex E)
From: "Marc K." <marck@omneon.com>
Date: Fri, 19 May 2000 00:06:47 GMT
Links: << >>  << T >>  << A >>

"Douglas Armstrong" <site@typhoon.xnet.com> wrote in message
news:8g1s12$d6e$1@flood.xnet.com...
> So is it better to have the DLL on the FPGA drive the clocks of components
> or to have a traditional clock multiplier with multiple outputs drive them
> and make sure there is no clok skew?

It's less risky but more expensive to use the external clock multiplier
(I'll refer to it as a clock driver from now on). That is, until you try
using the FPGA and find it works fine. Then it's just more expensive.

>
> We have a lot of parts to clock, SRAM, SDRAM, PCI, etc..  which approach
> is better?  We're using non -E parts which means only 4 DLLs.  Now, the
> system clock should drive one DLL directly (with feedback to itself) for
> the internal logic.  So the same IBUFG input from the global clock pin
> system clock can safely be split to multiple DLLs which drive normal OBUFs
> (not BUFGs)?  Should each DLL drive multiple OBUFs to go to each component
> with equal length traces or can it only drive one OBUF which has to then
> be split with an outside part to drive each component.
>

If all the clocks (SRAM, SDRAM, PCI, etc.) are the same, my previous
statement still applies. If they're not, then you'll run out of DLLs with
more than two clock domains. From my most recent post, you need two DLLs and
two global clocks inside a Virtex (-E or not) to provide the internal logic
clock and the mechanism for driving many output clocks from all over the
chip with minimal skew. This means a Virtex (-E or not) part can handle two
independent clock domains with my "special" clocking scheme. From my earlier
post (really XAPP132, which I referred to several times as XAPP133, sorry),
you still need two DLLs per clock domain if you're driving output clocks,
and you need to manage pin locations and routing carefully for multiple
outputs. The bottom line is, either way, if you choose to use the Virtex
part to drive output clocks, you can drive more than one. How many depends
on which technique you choose. If you have any thoughts about using clock
drivers to buffer clocks, use them at the oscillator and match trace lengths
to each driven device, including the Virtex part. As I said at the
beginning, that's the safe way to go. Normal clock routing rules apply to
all clocks, no matter the technique or source. Serpentine routing and
matched trace lengths are important. Too much loading can cause problems.
Termination is vital.

Also, don't bother sending a global clock pin through an IBUFG to multiple
DLLs. It doesn't buy you anything, unless you need several divided clocks,
e.g. /2 and /3. One DLL driving one BUFG can drive every single clock in the
device. If you're thinking of using more than one DLL to drive OBUFs
directly with the same clock (for routing purposes, I suppose), I'd advise
against it. I don't think you could rely on the outputs from the two DLLs
matching up.

Personally, if you have just one or two clock domains, I recommend the
"special" clocking I mentioned in my previous post. You don't need external
clock drivers for SRAM, or SDRAM, or PCI, etc., and the Virtex part will
provide as many buffered clocks as you want. Are you driving 16 SDRAMs? You
can choose to use 1, 2, 4, 8, or 16 separate clock outputs. And so on. The
Virtex OBUFs aren't quite as strong as a clock driver, so you need to keep
that in mind.

> Also, what are the PCB layout concerns for the feedback pin?  I'm assuming
> it needs a IBUFG pin.  And that it should be routed with an equal length
> as the traces going to th eother components.  Where is it best to split
> the trace?  does it matter much?  But I have hesitations of one OBUF
> driving the clock of, say, three PCI components and the feedback pin..
>

I've seen it done both ways on other chips. It all depends on your skew
budget. For what it's worth, I'd work hard to balance the load on each
output clock, and use a dedicated output as the feedback, complete with the
provision for a small capacitor to ground, so if you find there's a little
skew you want to correct for, you can. I'd match the trace lengths, and that
little capacitor would probably be 10pf or so, or, more accurately, it would
match the capacitive loading for your other clock lines. Also, the feedback
pin will go to an IBUFG.

By the way, just so you know, I've never used my "special" clocking scheme
exactly as I've described it. I've used it for output only, as a
source-synchronous clock for a transmit channel, and I didn't need to lock
the internal clock to the output. Instead, I relied on the phase
relationship of the internal clock to the output clock and to the output
data. Doesn't that fill you with confidence? The only difference between
what I've done and what I suggest is that I used just one DLL for the
internal logic clock and as the source for the "special" clock drivers. I
have looked at the routing and measured the skew among the output clocks,
though, and I have 4 coming off opposite sides of an FG456 package, and
there's about +-200ps skew among all 4 clocks. Taking that into account
along with XAPP132, I have complete confidence you can use the Virtex to
drive all the clocks you could want.

I hope this helps more than it confuses.


        Marc




Article: 22710
Subject: DCT and FPGA !!!!
From: "Seb C" <Seb@stien.bizland.com>
Date: Fri, 19 May 2000 01:54:17 GMT
Links: << >>  << T >>  << A >>
I've a small problem, i don't know how to perform a DCT (Discrete cosine
transform) implementation using FPGA for a picture for example, i can
compute DCT on a paper but not in XILINX for an FPGA, if some one can help
me, don't hesitate to do it !!

Thx in advance

SEB


Article: 22711
Subject: FPGA emultaion of a microprocessor
From: J.W. Krych <jwkrych@n2net.net>
Date: 18 May 2000 23:12:01 -0400
Links: << >>  << T >>  << A >>
Hello!

I am currently in the R & D phase of a potential new product. We need to 
have a replicated microprocessor, but have it running at far greater speeds 
than currently available through the normal manufacturer.

We are more than willing to use the much larger FPGA's out there to 
accomplish this. Anyone who has experience in creating/emulating computer 
designs with FPGA's, please get ahold of me. I will discuss more and have 
greater in-depth questions.


Regards,

Jim W. Krych
Article: 22712
Subject: Re: XC1804 JTAG Programming Problems
From: David Brown <dbrown@tigger.jvnc.net>
Date: Fri, 19 May 2000 03:29:53 GMT
Links: << >>  << T >>  << A >>
Simon,

Could you pass along any identifying numbers for the XC1804 devices you
were using? For example, date codes of JTAG device ID ? I want to avoid
repeating your discovery.

-Dave

Simon Ramirez wrote:
> 
> Peter,
>      There have been many problems in the JTAG Programming of Xilinx FPGAs.
> I believe that SP6 solves many problems but at least one problem remains.
> We found that the SPROM had to be the FIRST device in the chain or it
> doesn't program properly.  Also watch out for possible bad XC1804s -- the
> first ones had real big headache problems in them.
>      There are two kinds of problems here -- software problems in the JTAG
> program and hardware problems in the SPROM and possibly elsewhere.  Xilinx
> will readily admit to the software problems if you probe them enough.
> Getting data from them on hardware problems is next to impossible.
> Simon
> 
> > The boundary scan (JTAG) chain is built up in the following way:
> >
> > Parallel Cable III  ->  Virtex 600 ->  XC95144XL -> XC1804 -> back to
> > Parallel Cable III
> >
> > Chain intitialization is working, the JTAG SW gets the correct device
> > information.
> > The Virtex 600 can be configured and the circuit is working fine.
> > The CPLD 95144 hasn't been tried to configure yet.
> >
> > Are there any known bugs which can occur in this kind of JTAG chain?
> >
> > Are there any known bugs concerning the JTAG programmer software?
> >
> > Are there any known bugs concerning these brand new kind of PROM?
> >
> > Any kind of information concerning our problem is welcome.
> >
> >
> > Regards
> >
> > Peter Schulz
> > Signaal
> >
> >
> >
> >
Article: 22713
Subject: Re: FPGA emultaion of a microprocessor
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 19 May 2000 03:38:02 GMT
Links: << >>  << T >>  << A >>
In article <3924b101$1_2@athena.netset.com>,
J.W. Krych  <jwkrych@n2net.net> wrote:
>Hello!
>
>I am currently in the R & D phase of a potential new product. We need to 
>have a replicated microprocessor, but have it running at far greater speeds 
>than currently available through the normal manufacturer.
>
>We are more than willing to use the much larger FPGA's out there to 
>accomplish this. Anyone who has experience in creating/emulating computer 
>designs with FPGA's, please get ahold of me. I will discuss more and have 
>greater in-depth questions.

	In general, you take a performance hit on an FPGA.  You might
be able to, with some careful layout, be able to hit 100+ MHz but not
tha much faster, depending on how tightly you pipeline it.  (The
LEON1 runs at 40 MHz, SPARC clone).

	Question:  Just how much performance do you need, and what is
your base machine?  Could you translate your code to a more modern
microprocessor?  A StrongARM is pretty cheap and pretty darn fast, and
there are others out there as well.

	If you would see a significant speedbump by switching to an
FPGA, you might even be able to get away with just a software
emulation on a modern, high performance embedded processor.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 22714
Subject: Re: FPGA emultaion of a microprocessor
From: Ray Andraka <ray@andraka.com>
Date: Fri, 19 May 2000 04:11:01 GMT
Links: << >>  << T >>  << A >>
You're not likely to outperform a processor chip by emulating it on an FPGA,
unless it is really old technology.  Where FPGAs gain an advantage over
microprocessors is when you can create a circuit optimized for the task at hand
rather than generalized to handle a wide variety of tasks (eg microprocessor).
That said, you can make a fairly fast microprocessor in an FPGA, but you need
to architect it to take advantage of the FPGA structure.  Commercial CPU chips
generally do not map into the FPGA architecture very well.

"J.W. Krych" wrote:

> Hello!
>
> I am currently in the R & D phase of a potential new product. We need to
> have a replicated microprocessor, but have it running at far greater speeds
> than currently available through the normal manufacturer.
>
> We are more than willing to use the much larger FPGA's out there to
> accomplish this. Anyone who has experience in creating/emulating computer
> designs with FPGA's, please get ahold of me. I will discuss more and have
> greater in-depth questions.
>
> Regards,
>
> Jim W. Krych

--
P.S.  Please note the new email address and website url

-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com  or http://www.fpga-guru.com


Article: 22715
Subject: Re: FPGA emultaion of a microprocessor
From: Norbert Hoppe <hoppe@fh-brandenburg.de>
Date: Fri, 19 May 2000 08:29:49 +0200
Links: << >>  << T >>  << A >>
"J.W. Krych" schrieb:
> 
> Hello!
> 
> I am currently in the R & D phase of a potential new product. We need to
> have a replicated microprocessor, but have it running at far greater speeds
> than currently available through the normal manufacturer.
> 
> We are more than willing to use the much larger FPGA's out there to
> accomplish this. Anyone who has experience in creating/emulating computer
> designs with FPGA's, please get ahold of me. I will discuss more and have
> greater in-depth questions.

Have a look at www.arccores.com
Maybe they can help you.

Regards, Norbert Hoppe
Article: 22716
Subject: Printed magazines
From: "Thorsten Bunte" <t.bunte@beckhoff.de>
Date: Fri, 19 May 2000 09:07:29 +0200
Links: << >>  << T >>  << A >>
Hello,

Are there any vendor independent printed magazines about VHDL and/or
FPGA/ASIC designs available?

If yes, where can I get them in Germany?

Thanks in advance,

Thorsten




Article: 22717
Subject: Re: [Part II] - Pb FPGA Xilinx config process
From: fliptron@netcom.com (Philip Freidin)
Date: 19 May 2000 09:19:47 GMT
Links: << >>  << T >>  << A >>
In article <39214516.DFEB2C69@utc.fr>,
Sebastien Favard  <Sebastien.Favard@utc.fr> wrote:
>I open a new topic... (after the famous :) "Init/ line - CRC error ???")

Of course, it would be nice to know what factor on the previous thread
was the cause of the problem, so that you could advance to this new topic.

>
>I have buying a new XC5202 and I have progress on the programmation
>process step.
>
>Firstly, the HDC and LDC/ lines are correctly pull up and pull down
>respectively.

So the FPGA was sick???

>During the FPGA programmation step, the header is correctly detected and
>its bits are reported on DOUT. Just after the header, DOUT is hold at 5V
>:) and during the data stream, no crc error ic occured.
>

Thats encouraging.

>But after these things Done is hold at low and never pull up. So I think
>that I have a problem like my length count or perhaps my startup process
>? I use in fact CCLK to startup the FPGA, so I put some CCLK rising edge
>after the data stream to force my FPGA to start up.

Are you using the default startup sequence.

Default selects CCLK for the startup sequence. (which I recomend)

Do you have a pullup resistor on the done pin, 4.7K ohms.

How many extra clocks are you giving the FPGA. I usually give it
   an extra 16, just to be sure. (Do not change length count, just give 
   it extra clocks)

One test for the length count value being too low a value is to give
   the chip 16777216 extra clocks, and see if it goes done (i.e. causes
   the 24 bit counter to roll over.

At the end of the bitstream, you can append '01010101...' bits and keep 
   clocking the FPGA. The FPGA should output these bits on DOUT if the chip 
   has reached the "finished" stage, but there is a problem with length 
   count.

>
>Perhaps anyone has an idea about my new problem ! (maybe the
>FPGA banished me ;-) )

Keep trying. Hopefully once you have it all going, you will look back
on your problems and wonder why it didn't just work first time.

By the way, are you aware that the 5200 series is not a "preferred"
product for new designs. Spartan and Spartan II devices are faster, have
more features (like decent I/O cells, better carry logic, and on-chip
RAM), and they are cheaper. 

>Thanks a lot,
>Sebastien,

All the best,

Philip Freidin


Article: 22718
Subject: Re: Help with macrocell , explain it to me
From: Lee Weston <lee.weston@philips.com>
Date: Fri, 19 May 2000 09:23:16 GMT
Links: << >>  << T >>  << A >>
Eircom wrote:
> 
> Can some one explain
> 
> What is a macrocell
> It's use
> 
> keith@suparule.com

The programmable logic jump station has some useful pages, such as FAQ
on programmable logic and it does explain about macrocells.

http://www.optimagic.com/


Regards

Lee.

-- 
Lee Weston, Philips Semiconductors, CS-DM Southampton, SO15 0DJ, UK
mailto:lee.weston@philips.com                  seri:weston@ukpsshp1
phone: +44(0)1703 702 701 x6471                fax +44(0)1703316303
Article: 22719
Subject: Traning for Nallatech??
From: Allan James Cantle <a.cantle@nallatech.com>
Date: Fri, 19 May 2000 10:43:12 +0100
Links: << >>  << T >>  << A >>
Hi

We at Nallatech would be happy to provide training and support for our
products.

Regards

Allan


-----Original Message-----
From: A. [mailto:ahmad@frognet.net]
Posted At: 18 May 2000 05:39
Posted To: fpga
Conversation: Traning for Nallatech??
Subject: Traning for Nallatech??


Hi all..
we have Nallatech Virtex XV800 board. Is their any short training
courses
into how to use it?
Thank you in advanced.


Article: 22720
Subject: 68k - core
From: "Holger Azenhofer" <holger.azenhofer@vs.dasa.de>
Date: Fri, 19 May 2000 12:34:57 +0200
Links: << >>  << T >>  << A >>
Hi,

I'm looking for a 68k - core in order to replace an old 68000 design with an
fpga.
does someone know an 68k core and where to get it.
68020 would be fine.

thanks

Holger


Article: 22721
Subject: Re: FPGA emultaion of a microprocessor
From: husby@fnal.gov (Don Husby)
Date: Fri, 19 May 2000 13:23:10 GMT
Links: << >>  << T >>  << A >>
J.W. Krych <jwkrych@n2net.net> wrote:
> I am currently in the R & D phase of a potential new product. We need to 
> have a replicated microprocessor, but have it running at far greater speeds 
> than currently available through the normal manufacturer.

As mentioned by others, this is not a good fit for an FPGA.  One exception
might be a product announced by quicklogic that puts multiple ALUs and RAM
on a chip with an FPGA fabric:
   http://www.quicklogic.com/devices/dsp

There's a guy in my field (High Energy Physics) that for years has been
proposing to build a chip with many simple/fast CPUs optimized for processing
multiple real-time streams of data.   He has designs and software that you may
be able to use:
   http://www.3d-computing.com/



--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 22722
Subject: Re: 68k - core
From: elh@acadia.ee.vill.edu (Edward L. Hepler)
Date: 19 May 2000 10:25:39 -0400
Links: << >>  << T >>  << A >>
In article <8g35hv$sdu@newsserv.vs.dasa.de>,
Holger Azenhofer <holger.azenhofer@vs.dasa.de> wrote:
>Hi,
>
>I'm looking for a 68k - core in order to replace an old 68000 design with an
>fpga.
>does someone know an 68k core and where to get it.
>68020 would be fine.

VLSI Concepts offers a 68000 object code compatible core: V68000

See http://www.vlsi-concepts.com/V68000.html

or contact Ed Hepler:

  hepler@vlsi-concepts.com

for more information



Article: 22723
Subject: Re: PC104+ FPGA Board
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 19 May 2000 11:02:13 -0400
Links: << >>  << T >>  << A >>
Jean-Luc Nagel wrote:
> 
> Rick Collins wrote:
> 
> > How many boards do you think you will need? If the quantity is sufficient, I am
> > sure that someone will work with you to add such a board to their product line.
> 
> Well the quantity is rather small because we would only use these boards for a
> small number of demos. The asic is anyway the goal.
> Ok I guess I will forget PC104+ ! :)
> 
> --
> Jean-Luc


Maybe you can explain a little more about what you are doing and why you
are looking for a PC/104+ board rather than a standard PCI board. Is
your final product going to be PC/104+? Is there a reason that you can't
use a PCI to PC/104+ adaptor? I have read that there are sources for
such a converter board.


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



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: 22724
Subject: Re: Translate to verilog
From: Richard Iachetta <iachetta@us.ibm.com>
Date: Fri, 19 May 2000 14:36:11 -0500
Links: << >>  << T >>  << A >>
In article <8g01ig$6rs$1@okapi.ict.pwr.wroc.pl>, 
tbrychcy@sensor.ime.pz.zgora.pl says...
> Hello,
> 
> I would like translate the part of vhdl source to verilog. Please about
> correct translation the fragment of vhdl.
> 
> process(READ,RESET)
>  begin
>   if (RESET='1') then
>    BYTE<='0';
>   elsif (RISING_EDGE(READ)) then
>    if (CS='1' and BACK='0') then
>     BYTE<=not BYTE;
>    end if;
>   end if;
>  end process;

always @(posedge READ or posedge RESET)
   if (RESET)
      BYTE <= 0;
   else if (CS & ~BACK)
      BYTE <= ~BYTE;

-- 
Rich Iachetta
iachetta@us.ibm.com
I do not speak for IBM.


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

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