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 123775

Article: 123775
Subject: Re: Multiple CPLDs on a PCB.
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 05 Sep 2007 07:47:40 +1200
Links: << >>  << T >>  << A >>
NickNitro wrote:
> Hi,
> 
> Apologies if this isn't the best group, but there doesn't appear to be
> a comp.arch.cpld group.
> 
> I'm going to start learning about CPLDs to use them in my projects,
> but the algorithm I've developed will require a few CPLDs working on
> different parts of the algorithm in sequence. So part A of the
> algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. 

Probably not the best direction.

> They
> are all complete guesses at the moment, as I know next to nothing
> about PLDs in general, but I know that for my algorithm to run as fast
> as required, I will require multiple PLDs. I'm choosing CPLDs as from
> what I've read FPGAs can be a bit overbearing for a beginner due to
> the amount of features/number of gates they have, 

You do not have to use all features on the first pass :)

> also CPLDs have more predictable timing?

On simple designs, yes. As multiple CPLDs get into the frame, it gets
harder.

> 
> So, I'm wondering just how difficult using multiple CPLDs on a custom
> PCB actually is? I'm sure it's achievable, but I would like to know
> how difficult this could be.

The real fish-hook comes, when you find "Part B" really needed 9 devices!

> Also, could any simulators be used to
> simulate a complex design with multiple CPLDs on a PCB?

Not easily. You _could_ have two designs, one that is partitioned
into the smaller blocks, and another that is the whole system.
The whole system one would simulate - but you may have spotted by
now, that such a whole systemm design, is a FPGA design flow :)

> Finally, could
> anybody recommend any books for getting started in the CPLD world -
> I'm unsure to use Verilog or VHDL at the moment?

Download the development tools, and try some code in each.
Search for come examples close to what you want to do.
The tools can target BOTH cpld, and FPGA (& both languages),
so you can actually get quite advanced in the design, before you commit 
to a PCB design. (or even a final device)

There are also cross-over CPLDs like MAX II and MachXO, and
also the FLASH FPGAs from Actel and Lattice to look into.

Give a short list if what your design needs to do, and someone here
might suggest a device family, and an expected speed range.

-jg



Article: 123776
Subject: vnavigator problem
From: kkoorndyk <kris.koorndyk@gmail.com>
Date: Tue, 04 Sep 2007 19:50:55 -0000
Links: << >>  << T >>  << A >>
Hello all,

I am working on merging code coverage results in Verification
Navigator from TransEDA.  I am encountering an error that I can't seem
to figure out a solution for.

Has anyone here ever used vnavigator?

Here's the problem.  When attempting to merge multiple results
directories, I run the following:

# vnmerge -verbose on e3_results/vnavigator_results e2_results/
vnavigator_results e4_results/vnavigator_results -log_file
all_merge.log -save merged_results

Verification Navigator version 2004.06(Build VN406-0-00), Copyright
1994-2003 TransEDA Technology Ltd

Merging the following components:
Index Files:    /home/osprey/users/XXXXXX/e3_results/
vnavigator_results/vnavigator.index
                /home/osprey/users/XXXXXX/e2_results/
vnavigator_results/vnavigator.index
                /home/osprey/users/XXXXXX/e4_results/
vnavigator_results/vnavigator.index
Merging into target directory: /home/osprey/users/XXXXXX/
merged_results
Error: vnmerge_history execution failed. Merge aborted.



Um.  Okay.  There is no documentation on the "vnmerge_history"
function in the documents.  Running it on it's own appears to work
without error.

# vnmerge_history e2_results/vnavigator_results/vnavigator.history
e3_results/vnavigator_results/vnavigator.history e4_results/
vnavigator_results/vnavigator.history -log_file vnmerge_history.log -
verbose -save merged_results/vnavigator.history

Verification Navigator version 2004.06(Build VN406-0-00), Copyright
1994-2004 TransEDA Technology Ltd
Reading instances from history files...
  Processing e2_results/vnavigator_results/vnavigator.history
  Processing e3_results/vnavigator_results/vnavigator.history
  Processing e4_results/vnavigator_results/vnavigator.history
Loading coverage from history files...
  Processing e2_results/vnavigator_results/vnavigator.history
  Processing e3_results/vnavigator_results/vnavigator.history
  Processing e4_results/vnavigator_results/vnavigator.history
Merging instance coverage...
  Processing instance t.XXXXXX
  Processing instance t.XXXXXX
  Processing instance t.XXXXXX
  Processing instance t.XXXXXX
  Processing instance t.XXXXXX
  Processing instance t.XXXXXX
  Processing instance t.XXXXXX
  Processing instance t.XXXXXX



Viewing the log file:

# cat vnmerge_history.log
Date: Tue Sep  4 15:47:35 2007

3 files were merged into merged_results/vnavigator.history
e2_results/vnavigator_results/vnavigator.history
e3_results/vnavigator_results/vnavigator.history
e4_results/vnavigator_results/vnavigator.history

0 files were rejected because of errors



So what's the problem?  Has anyone encountered this before?  I have
been playing around with options and attempted to merge using the GUI
with the same error.  With TranEDA out of business now, I'm running
out of options to determine a solution.

Thanks in advance.


Article: 123777
Subject: Re: PCB Impedance Control
From: vasile <piclist9@gmail.com>
Date: Tue, 04 Sep 2007 19:52:44 -0000
Links: << >>  << T >>  << A >>
On Sep 4, 1:42 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> John Larkin wrote:
>
> (snip)
>
> > Incredible, dangerous nonsense. Absolutely moronic. Quote:
> > "Referencing the Top and Bottom of the Same Plane.  Whenever a signal
> > switches layers and references first the top and then the bottom of
> > the same plane we must still ask the question, how does the return
> > current get from the top to the bottom of the plane.  Do to the "skin
> > effect" the current cannot flow through the plane, it can only flow on
> > the surface of the plane.
> > This is some sort of joke, right?
>
> It would seem to me that it would go around the hole for the via.
> At least it could do that.
>
> (snip)
>
> > Except in extreme situations, it's safe to assume that parallel planes
> > in a multilayer pcb, bypassed with scattered caps, is an equipotential
> > structure. It's that simple.
>
> With sufficient distributed capacitance, due to both the planes
> themselves and bypass capacitors, I would agree.  Note that a plane
> still has capacitance even without another nearby plane.  

??? The physics laws are different in your area ?
thx,
Vasile


Article: 123778
Subject: Re: FPGA CPU
From: fpga_toys@yahoo.com
Date: Tue, 04 Sep 2007 12:55:33 -0700
Links: << >>  << T >>  << A >>
On Sep 2, 4:43 pm, James Harris <james.harri...@googlemail.com> wrote:
> Should have said that part of the design is a large crossbar switch.
> It may be relevant to the number of gates and/or the design style.

should have asked, what's the data rate thru the cross bar per port?

There are sometimes cheaper alternatives to a cross bar, such as
message switching.


Article: 123779
Subject: Re: PCB Impedance Control
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 04 Sep 2007 12:42:36 -0800
Links: << >>  << T >>  << A >>
John Larkin wrote:
(snip)

> Incredible, dangerous nonsense. Absolutely moronic. Quote:

> "Referencing the Top and Bottom of the Same Plane.  Whenever a signal
> switches layers and references first the top and then the bottom of
> the same plane we must still ask the question, how does the return
> current get from the top to the bottom of the plane.  Do to the "skin
> effect" the current cannot flow through the plane, it can only flow on
> the surface of the plane.

> This is some sort of joke, right?

It would seem to me that it would go around the hole for the via.
At least it could do that.

(snip)

> Except in extreme situations, it's safe to assume that parallel planes
> in a multilayer pcb, bypassed with scattered caps, is an equipotential
> structure. It's that simple.

With sufficient distributed capacitance, due to both the planes 
themselves and bypass capacitors, I would agree.  Note that a plane
still has capacitance even without another nearby plane.  For a wide
plane and a narrow wire, it is likely that the relative capacitance
is fairly high.

-- glen


Article: 123780
Subject: Re: Spartan3E and DDR termination
From: Gabor <gabor@alacron.com>
Date: Tue, 04 Sep 2007 13:42:36 -0700
Links: << >>  << T >>  << A >>
On Sep 4, 3:40 pm, vasile <picli...@gmail.com> wrote:
> On Aug 30, 8:41 am, Gabor <ga...@alacron.com> wrote:
>
>
>
> > On Aug 30, 9:41 am, Gabor <ga...@alacron.com> wrote:
>
> > > On Aug 30, 4:59 am, Guru <ales.gor...@email.si> wrote:
>
> > > > Hi all,
>
> > > > We are building a board with Spartan3E (XC3S1200E FG320) and a 64MB
> > > > x16 DDR (HYB25DC512160CF-6). Trying to make the board as tiny as
> > > > possible the DDR termination presents a problem. Since the Spartan3E
> > > > does not have DCI, termination on chip is not possible. This means
> > > > that 44 termination resistors should be added and maybe a VTT power
> > > > source. The other problem is that according to MIG we should connect
> > > > DDR to two banks.
>
> > > > Any good suggestions?
> > > > Is it possible to eliminate termination resistors?
>
> > > > Cheers,
>
> > > > Guru
>
> > > If you're only driving a single chip with very short lines you
> > > can probably get away without termination on everything except
> > > the clock.  I would suggest using SSTL2_I instead of SSTL2_II
> > > to avoid overdriving.  Another approach is to just leave out
> > > the series termination on these signals and just add the parallel
> > > termination to Vtt.  I've used the latter method with Virtex2
> > > and an SO-DIMM without DCI on the data lines and SSTL2_I drive.
> > > A good argument for leaving out the series termination is any
> > > net where the driving stub (from the S3 to the resistor) is
> > > about the same length as the driven stub (from the resistor
> > > to the memory).  Here the terminator is of dubious value.
>
> > > It's probably best to simulate your transmission lines,
> > > especially if you're planning to run the memory at its
> > > maximum speed of 166 MHz / DDR333.  My V2 design ran at
> > > 133 MHz / DDR266.
>
> > > HTH,
> > > Gabor
>
> > One other thought if your main interest is in reducing the
> > board size.  Often I find that using a x32 single-data-rate
> > (143 MHz) memory can save space.  If you're using a TSSOP-66
> > package for the DDR part, the 86-pin TSSOP for the x32 SDR
> > part has the same footprint and runs from +3.3V with no
> > requirements for VREF and DQS pins on the FPGA and no
> > Vtt or 2.5V supply.
>
> How looks the Vref signal inside the DDR II ? Exactly what is good
> for ?
>
> thx,
> Vasile


Not quite sure what you're asking here.  The point I was trying to
make
is that the single-data-rate parts don't need to tie up FPGA pins with
Vref and DCI.  On Virtex 2 parts, you can have as many as 6 Vref pins
in one bank.  If you use SSTL2 signalling instead of LVTTL you lose
the ability to use these pins as I/O.  If you also decide to use DCI
you lose an additional 2 pins per bank.  The DDR parts also have more
control pins (differential clock adds one pin, DQS adds one per 8 bits
of interface).  So if you can live with the data rates of the single-
data-rate parts, you can avoid a lot of headaches and perhaps use
only a small number of additional pins to double the data width.

By the way, for SSTL2 you need Vref as a precision threshold reference
at 1/2 Vddq, usually 1.25V or 1.3V depending on the speed for DDR I
parts.  LVTTL allows a wide threshold tolerance, usually 0.8 to 2.0v
but generally won't work well at DDR bit rates.


Article: 123781
Subject: Re: Beginning FPGA programming
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 04 Sep 2007 12:48:03 -0800
Links: << >>  << T >>  << A >>
James Harris wrote:

> I'd like to try out some ideas and would appreciate some guidance.
> Would a 200k-gate FPGA be enough for a simple or complex 8-bit CPU
> design? 

I think that should be enough for a good sized CPU.  Maybe for
some of the support logic, also.

(snip)

> 1. What language would be suitable - VHDL or Verilog? Or are there
> others?

That is about equivalent to asking if you should use Ada or C
for software development.  Either will work in most cases,
one likely suits you better.

> 2. What description style would be appropriate? Or can I break the
> design into modules, initially make each module with a high level
> description and rewrite it at a lower level later as needed?

As with software, the appropriate level of modularization is
up to you.  Both verilog and VHDL allow modules.  With many
you can mix VHDL and verilog modules in the same design
(along with schematic capture and a few other languages).

-- glen


Article: 123782
Subject: Re: Spartan3E and DDR termination
From: Ben Jackson <ben@ben.com>
Date: Tue, 04 Sep 2007 15:48:19 -0500
Links: << >>  << T >>  << A >>
On 2007-09-02, Guru <ales.gorkic@email.si> wrote:
> What about 8 bit DDR2? This way I can get away with only one FPGA bank
> and layout to MIG rules.
> Did anyone used it with MPMC2 (x8 is not supported by MCH_OPB_DDR2)?

Double check that MPMC2 uses ODT.  I'm not sure it does.  Otherwise DDR2
is a big win if you are worried about signal integrity.  If you've seen
a DDR design go wrong, the DDR2 data sheets will make you say, "wow, that
would have been handy!" about 100 times.

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 123783
Subject: Re: Multiple CPLDs on a PCB.
From: Gabor <gabor@alacron.com>
Date: Tue, 04 Sep 2007 14:03:01 -0700
Links: << >>  << T >>  << A >>
On Sep 4, 2:08 pm, NickNitro <NickHo...@googlemail.com> wrote:
> Hi,
>
> Apologies if this isn't the best group, but there doesn't appear to be
> a comp.arch.cpld group.
>
> I'm going to start learning about CPLDs to use them in my projects,
> but the algorithm I've developed will require a few CPLDs working on
> different parts of the algorithm in sequence. So part A of the
> algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. They
> are all complete guesses at the moment, as I know next to nothing
> about PLDs in general, but I know that for my algorithm to run as fast
> as required, I will require multiple PLDs. I'm choosing CPLDs as from
> what I've read FPGAs can be a bit overbearing for a beginner due to
> the amount of features/number of gates they have, also CPLDs have more
> predictable timing?
>

As someone who started designing with TTL, then PALs and GALs,
then CPLDs, then FPGAs, I would take issue with that reasoning.
I find FPGA's much easier to use if the alternative means using
multiple of any sort of part.  Generally there is a big advantage
to fitting a design in a single part.  Partitioning the design
was always the biggest part of the design process when I used
the smaller parts.  Fitting the design in a single part also
frees you from reworking your PC board when you realize you
needed another signal in one of the CPLD's, or you run out of
macrocells or internal routing.

Once you have made the decision to use a high-level language
to design your logic, using an FPGA becomes actually simpler
than the multiple CPLD approach.  Also while CPLD's may
have predictable timing, modern FPGA's have such fast internal
timing that you generally can meet timing easily for nearly any
design that runs in a CPLD.  Even pin-to-pin timing can be
fast in FPGA's nowadays.  And if you look at the timing of the
signals you route from one CPLD to another, and think of
using only internal FPGA timing on those, you may find the
design running considerably faster.  Depending on your
algorithm CPLD's can be bad for timing.  For example if
your equations end up with too many product terms you
suddenly double the delay.  You didn't mention the clock
speeds you're shooting for, but those superfast CPLD's aren't
so hot if you need to go through 2 macrocells or more
between registers.

Also think of all of the connections you don't need to make
when your design fits in one part.  O.K. you don't have all
those extra points to scope on when you debug, but there are
better tools for debugging in FPGA's that don't require
physical access to the chip guts (see ChipScope on the
Xilinx site or ispTracy from Lattice).

> So, I'm wondering just how difficult using multiple CPLDs on a custom
> PCB actually is? I'm sure it's achievable, but I would like to know
> how difficult this could be. Also, could any simulators be used to
> simulate a complex design with multiple CPLDs on a PCB? Finally, could
> anybody recommend any books for getting started in the CPLD world -
> I'm unsure to use Verilog or VHDL at the moment?
>

There are plenty of threads on the language selection.  No need
to start up another one here.  Google for Verilog vs VHDL for
some heated discussions.  Also check out comp.lang.verilog and
comp.lang.vhdl for lots of threads on books for newbies, etc.

> Thanks for your time.
> Nick.

Good Luck,
Gabor


Article: 123784
Subject: Re: Multiple CPLDs on a PCB.
From: NickNitro <NickHolby@googlemail.com>
Date: Tue, 04 Sep 2007 14:03:03 -0700
Links: << >>  << T >>  << A >>
Hi Jim,

Thanks for taking the time out to reply.
> > I'm going to start learning about CPLDs to use them in my projects,
> > but the algorithm I've developed will require a few CPLDs working on
> > different parts of the algorithm in sequence. So part A of the
> > algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs.
> Probably not the best direction.

May I ask why?


> The real fish-hook comes, when you find "Part B" really needed 9 devices!

But if everything is solidly designed before code is started, then
this shouldn't happen?


> Not easily. You _could_ have two designs, one that is partitioned
> into the smaller blocks, and another that is the whole system.
> The whole system one would simulate - but you may have spotted by
> now, that such a whole systemm design, is a FPGA design flow :)

If done correctly though wouldn't multiple CPLDs working on different
parts of the algorithm perform better overall than a single FPGA?


> Download the development tools, and try some code in each.
> Search for come examples close to what you want to do.
> The tools can target BOTH cpld, and FPGA (& both languages),
> so you can actually get quite advanced in the design, before you commit
> to a PCB design. (or even a final device)
>
> There are also cross-over CPLDs like MAX II and MachXO, and
> also the FLASH FPGAs from Actel and Lattice to look into.

Appreciated, I'll have a look.

Thanks again,
Nick.


Article: 123785
Subject: Re: FPGA CPU
From: James Harris <james.harris.1@googlemail.com>
Date: Tue, 04 Sep 2007 14:20:47 -0700
Links: << >>  << T >>  << A >>
On 3 Sep, 13:33, Andreas Ehliar <ehl...@lysator.liu.se> wrote:
...
> I don't remember any exact reference now but I remember reading postings
> on this group saying that it might be better to pipeline an FPGA
> design more than you might think since hazard spikes propagating through
> a long net might consume more power than the network itself. Something
> to keep in mind at least. I haven't tried to verify this myself though.
> Searching the group should yield some references which you might be
> interested in evaluating before you start working on this.

Simplistically, I'm thinking that each compute element (effectively
each part of the ALU) would raise or lower an output-ready indicator
just after its output lines had stabilised. When the next component
has read the output of that compute element it would strobe an
acknowledge line. The compute element would then reset its output-
ready line and be free to take on another piece of work. I guess this
is simple handshaking.

I've tried a search for clockless CPU which is a good summary of what
I have in mind. Some posts said others had thought of it but it would
be almost impossible to test but I cannot see why. I tried a search
for hazard spikes and got your post, above!

The idea makes sense to me but then it is admittedly very simplistic.

--
James


Article: 123786
Subject: Re: FPGA CPU
From: James Harris <james.harris.1@googlemail.com>
Date: Tue, 04 Sep 2007 14:28:00 -0700
Links: << >>  << T >>  << A >>
On 4 Sep, 19:38, fpga_t...@yahoo.com wrote:
...
> Isn't that a 7x7 crossbar with 10 bit data path , 3 bits of addressing
> to specify a port?
> total size would be 10*2*7=140 LUTs for crossbar port input mux tree.

Quite possibly.

> Much different problem than a 70x70 single bit data path with 7 bits
> of addressing.
> That problem requires 70*64=4,480 LUTs.

Each output bit would only come from one of 7 inputs, yes, not one
from 70. An output bit zero could only come from one of the input bits
zero.


Article: 123787
Subject: Re: FPGA CPU
From: James Harris <james.harris.1@googlemail.com>
Date: Tue, 04 Sep 2007 14:30:25 -0700
Links: << >>  << T >>  << A >>
On 4 Sep, 20:55, fpga_t...@yahoo.com wrote:
> On Sep 2, 4:43 pm, James Harris <james.harri...@googlemail.com> wrote:
>
> > Should have said that part of the design is a large crossbar switch.
> > It may be relevant to the number of gates and/or the design style.
>
> should have asked, what's the data rate thru the cross bar per port?
>
> There are sometimes cheaper alternatives to a cross bar, such as
> message switching.

I think most alternatives are not non-blocking which is the main
characteristic I want from the switching system. That said, the
switching part of the idea is independent of other parts so the design
of the switch should affect performance but not correctness.


Article: 123788
Subject: Re: FPGA CPU
From: Frank Buss <fb@frank-buss.de>
Date: Tue, 4 Sep 2007 23:31:19 +0200
Links: << >>  << T >>  << A >>
James Harris wrote:

> Simplistically, I'm thinking that each compute element (effectively
> each part of the ALU) would raise or lower an output-ready indicator
> just after its output lines had stabilised. When the next component
> has read the output of that compute element it would strobe an
> acknowledge line. The compute element would then reset its output-
> ready line and be free to take on another piece of work. I guess this
> is simple handshaking.

Some keywords for searching are dual-rail signalling and Muller C gate.

It sounds interesting, but I didn't tried it and some earlier postings in
this newsgroup suggests that unclocked designs are not very well supported
by FPGA synthesis tools, like Xilinx ISE and Altera Quartus, and they are
more difficult to design.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 123789
Subject: Re: PCB Impedance Control
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 04 Sep 2007 14:42:25 -0700
Links: << >>  << T >>  << A >>
On Tue, 04 Sep 2007 19:52:44 -0000, vasile <piclist9@gmail.com> wrote:

>On Sep 4, 1:42 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> John Larkin wrote:
>>
>> (snip)
>>
>> > Incredible, dangerous nonsense. Absolutely moronic. Quote:
>> > "Referencing the Top and Bottom of the Same Plane.  Whenever a signal
>> > switches layers and references first the top and then the bottom of
>> > the same plane we must still ask the question, how does the return
>> > current get from the top to the bottom of the plane.  Do to the "skin
>> > effect" the current cannot flow through the plane, it can only flow on
>> > the surface of the plane.
>> > This is some sort of joke, right?
>>
>> It would seem to me that it would go around the hole for the via.
>> At least it could do that.
>>
>> (snip)
>>
>> > Except in extreme situations, it's safe to assume that parallel planes
>> > in a multilayer pcb, bypassed with scattered caps, is an equipotential
>> > structure. It's that simple.
>>
>> With sufficient distributed capacitance, due to both the planes
>> themselves and bypass capacitors, I would agree.  Note that a plane
>> still has capacitance even without another nearby plane.  
>
>??? The physics laws are different in your area ?
>thx,
>Vasile

"My area" is the universe, and everything has capacitance to the
universe. Where do you live?

John


Article: 123790
Subject: Re: Multiple CPLDs on a PCB.
From: NickNitro <NickHolby@googlemail.com>
Date: Tue, 04 Sep 2007 14:43:57 -0700
Links: << >>  << T >>  << A >>
> Gabor wrote:
<snip>

Hi Gabor,

The only thing is is that my algorithm has to work on 2^17 bits, all
in one go, so it would have to work on one group then another group
then another etc... until it has worked on all groups of bits.
However, with the constant input output to the fpga I thought it would
be a major delay, so I (naively) assumed using multiple CPLDs would be
best because they would have the same wire delay as that as an fpga.

>>You didn't mention the clock speeds you're shooting for, but those superfast CPLD's aren't so hot if you need to go through 2 macrocells or more between registers.
Well to be honest I don't have a clue. But I again naively assumed
that having more than one pld working on the problem would be better
than one pld working on the problem.

>>There are plenty of threads on the language selection.  No need to start up another one here.
Apologies, I wasn't intending to create a flame war, but instead
hoping for suggestions on a book or two that would give me the pros
and cons of the languages to help me make a decision.

>>Good Luck,
I'm needing a bit more than luck I think for something as ambitious
this - thanks anyway.

Nick.


Article: 123791
Subject: Re: Multiple CPLDs on a PCB.
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 05 Sep 2007 10:15:53 +1200
Links: << >>  << T >>  << A >>
NickNitro wrote:

> Hi Jim,
> 
> Thanks for taking the time out to reply.
> 
>>>I'm going to start learning about CPLDs to use them in my projects,
>>>but the algorithm I've developed will require a few CPLDs working on
>>>different parts of the algorithm in sequence. So part A of the
>>>algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs.
>>
>>Probably not the best direction.
> 
> 
> May I ask why?

My subsequent comments explained why.

> 
> 
>>The real fish-hook comes, when you find "Part B" really needed 9 devices!
> 
> 
> But if everything is solidly designed before code is started, then
> this shouldn't happen?

Perhaps in theory, but 'algortihm development' is a very fluid thing, 
and a good designer allows for late changes.

> 
>>Not easily. You _could_ have two designs, one that is partitioned
>>into the smaller blocks, and another that is the whole system.
>>The whole system one would simulate - but you may have spotted by
>>now, that such a whole systemm design, is a FPGA design flow :)
> 
> 
> If done correctly though wouldn't multiple CPLDs working on different
> parts of the algorithm perform better overall than a single FPGA?

That would depend on the design details, which is why you should get the 
tools, and actually implement the design before starting the PCB.

Device retargeting is not difficult.

-jg


Article: 123792
Subject: Re: FPGA CPU
From: fpga_toys@yahoo.com
Date: Tue, 04 Sep 2007 15:16:16 -0700
Links: << >>  << T >>  << A >>
On Sep 4, 3:28 pm, James Harris <james.harri...@googlemail.com> wrote:
> On 4 Sep, 19:38, fpga_t...@yahoo.com wrote:
> ...
>
> > Isn't that a 7x7 crossbar with 10 bit data path , 3 bits of addressing
> > to specify a port?
> > total size would be 10*2*7=140 LUTs for crossbar port input mux tree.
>
> Quite possibly.
>
> > Much different problem than a 70x70 single bit data path with 7 bits
> > of addressing.
> > That problem requires 70*64=4,480 LUTs.
>
> Each output bit would only come from one of 7 inputs, yes, not one
> from 70. An output bit zero could only come from one of the input bits
> zero.

with 7 ports total, ignoring loopback, there are 6 other sources. You
can pack a 3:1 mux into the LUT and carry logic, with some tricks ...
reference Carl Brannen's posts in this forum back around Dec 2001.  I
gave Carl's post to Guerric who took the paper and did 3:1 muxes for
our d.net RC5 fpga core to cut the barrel shifter depth and area - not
pretty, but dense and fast with constrained routing.

The cpu side of the project sounds more fun ... :)


Article: 123793
Subject: Re: Multiple CPLDs on a PCB.
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 04 Sep 2007 17:20:23 -0500
Links: << >>  << T >>  << A >>
>> The real fish-hook comes, when you find "Part B" really needed 9 devices!
>
>But if everything is solidly designed before code is started, then
>this shouldn't happen?

Don't you ever get a new idea after a design has been running for
a while?


> If done correctly though wouldn't multiple CPLDs working on different
> parts of the algorithm perform better overall than a single FPGA?

Why would you think that way?  Getting on/off chip is usually slow.

If your FPGA is big enough to hold the whole design, I'd expect it
to be faster.

CPLDs generally have wide inputs relative to LUTs in FPGAs.
There are probably some designs that will be faster on CPLDs
because they take advantage of that.


Another potential advantage of FPGAs is that you can get
prototype boards that might be good enough for your problem.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 123794
Subject: Re: FPGA CPU
From: fpga_toys@yahoo.com
Date: Tue, 04 Sep 2007 15:37:34 -0700
Links: << >>  << T >>  << A >>
On Sep 4, 3:30 pm, James Harris <james.harri...@googlemail.com> wrote:

> I think most alternatives are not non-blocking which is the main
> characteristic I want from the switching system. That said, the
> switching part of the idea is independent of other parts so the design
> of the switch should affect performance but not correctness.

The reason I asked about data rate, is another dense architecture is
a 7x TDM using one 10 bit wide mux tree to sample all inputs as a
front end, and backend it into 7 SRL's with the tap set to the desired
channel, with the SRL's  FF clocked at 1/7th the data clock. Very
small crossbar design, but the external frequency can not be faster
the 1/7th the core TDM rate if sync, or would need over clocking if
async. Fits into about 15-20 slices with some handy work. Input mux is
10 slices, another 3-1/2 for 7 SRL lanes, and a few more for timing
logic. The SRL cycle timing will limit your clock rate.


Article: 123795
Subject: Re: Multiple CPLDs on a PCB.
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 04 Sep 2007 15:49:13 -0700
Links: << >>  << T >>  << A >>
Nick, you are much better off doing this design inside one FPGA, even
if you have to operate sequentially on 128000 bits (is that what you
really meant with 2^17 bits?)
I would also use one of the many existing evaluation boards, which
eliminates a lot of work, time, money, and risk. I would focus on one
of the Xilinx Spartan evaluation boards, and go to a Virtex-4
evaluation board only if the design really mushrooms (which I doubt)

I would first sketch out the basic design on paper, to easily see the
speed bottlnecks, but that may just be my style...
Peter Alfke, Xilinx
============================


Article: 123796
Subject: Re: FPGA CPU
From: James Harris <james.harris.1@googlemail.com>
Date: Tue, 04 Sep 2007 15:49:35 -0700
Links: << >>  << T >>  << A >>
On 4 Sep, 23:16, fpga_t...@yahoo.com wrote:
...
> The cpu side of the project sounds more fun ... :)

It's great that you like the idea. In fact the crossbar is intended to
be the main way values get from one compute element to another so it
is really part of the CPU. I have no idea how I am going to control
operations yet - i.e. select what operations happen and in what order,
and where the results are to be stored (without the cost of passing
the control info through the switch). Sure, it should be fun to work
it through.



Article: 123797
Subject: Re: FPGA CPU
From: fpga_toys@yahoo.com
Date: Tue, 04 Sep 2007 15:53:30 -0700
Links: << >>  << T >>  << A >>
On Sep 4, 4:37 pm, fpga_t...@yahoo.com wrote:
> On Sep 4, 3:30 pm, James Harris <james.harri...@googlemail.com> wrote:
>
> > I think most alternatives are not non-blocking which is the main
> > characteristic I want from the switching system. That said, the
> > switching part of the idea is independent of other parts so the design
> > of the switch should affect performance but not correctness.
>
> The reason I asked about data rate, is another dense architecture is
> a 7x TDM using one 10 bit wide mux tree to sample all inputs as a
> front end, and backend it into 7 SRL's with the tap set to the desired
> channel, with the SRL's  FF clocked at 1/7th the data clock. Very
> small crossbar design, but the external frequency can not be faster
> the 1/7th the core TDM rate if sync, or would need over clocking if
> async. Fits into about 15-20 slices with some handy work. Input mux is
> 10 slices, another 3-1/2 for 7 SRL lanes, and a few more for timing
> logic. The SRL cycle timing will limit your clock rate.

hmm ... forgot to add up the FF's required ... 70+ of FF's ... so a
little over 40 slices :(


Article: 123798
Subject: Re: Multiple CPLDs on a PCB.
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Tue, 04 Sep 2007 17:45:43 -0700
Links: << >>  << T >>  << A >>
On Tue, 04 Sep 2007 11:08:49 -0700, NickNitro
<NickHolby@googlemail.com> wrote:

>Hi,
>
>Apologies if this isn't the best group, but there doesn't appear to be
>a comp.arch.cpld group.
>
>I'm going to start learning about CPLDs to use them in my projects,
>but the algorithm I've developed will require a few CPLDs working on
>different parts of the algorithm in sequence. So part A of the
>algorithm may require 5 CPLDs, part B 8 CPLDs and part C 3 CPLDs. They
>are all complete guesses at the moment, as I know next to nothing
>about PLDs in general, but I know that for my algorithm to run as fast
>as required, I will require multiple PLDs. I'm choosing CPLDs as from
>what I've read FPGAs can be a bit overbearing for a beginner due to
>the amount of features/number of gates they have, also CPLDs have more
>predictable timing?
>
>So, I'm wondering just how difficult using multiple CPLDs on a custom
>PCB actually is? I'm sure it's achievable, but I would like to know
>how difficult this could be. Also, could any simulators be used to
>simulate a complex design with multiple CPLDs on a PCB? Finally, could
>anybody recommend any books for getting started in the CPLD world -
>I'm unsure to use Verilog or VHDL at the moment?
>
>Thanks for your time.
>Nick.

I'd recommend using an FPGA. The CPLD pins/interconnects can be
deadly, not to mention slow. And as you mention, simulation of the
entire design is a lot easier if it's all in one chip.

John




Article: 123799
Subject: Re: Multiple CPLDs on a PCB.
From: NickNitro <NickHolby@googlemail.com>
Date: Tue, 04 Sep 2007 18:54:53 -0700
Links: << >>  << T >>  << A >>
Hi all,

>>Perhaps in theory, but 'algortihm development' is a very fluid thing, and a good designer allows for late changes.
Well I don't think I've mentioned just how far the algorithm is
through development, although is it completely designed and has been
finalised by many people and all have signed it off. It has been
designed down to the bit level and has been tested in a software
environment with no flaws (strong words, but every possible scenario
has been tested through brute forcing, so nothing has been missed); so
I can safely say the algorithm being altered at this stage won't
happen.

>>Device retargeting is not difficult.
I've done what you've suggested and had a look at the Xilinx web pack
and if I've done it correctly, device retargeting seems to be just be
selecting a different device from the list? Or am I greatly
oversimplifying to what I imagine?

>>Don't you ever get a new idea after a design has been running for a while?
Very much, although as above, the algorithm is set in concrete.

>>Why would you think that way?  Getting on/off chip is usually slow.
Naivety. ;) I'm coming from a software background, so unfortunately
I'm relying on software knowledge, where more cores==better
performance.

>>CPLDs generally have wide inputs relative to LUTs in FPGAs. There are probably some designs that will be faster on CPLDs because they take advantage of that.
I'm afraid I don't have a clue what 'wide inputs' are, but I'll take
your word at it. ;)

>>even if you have to operate sequentially on 128000 bits
Yes, that's correct.

>>I would also use one of the many existing evaluation boards, which eliminates a lot of work, time, money, and risk.
Thing is, once it's working fine in the FPGA/evaluation board
environment, I'll still need to move the chip to a custom PCB so it
has the correct peripherals?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - -

Speed is extremley important to this problem, I'm not too worried
about the difficulty of this - just the final result; since ideally
execution of the algorithm cannot take more than 15-20 milliseconds. I
hope you don't think I'm being completely ignorant and rude asking
this, nor do I want you to think that I don't appreciate your advice -
although I can't help but think something like the following would be
faster - I'm stuggling to shake off my software thinking:

http://img529.imageshack.us/img529/9474/cpldlayoutus9.jpg

Where 32 bits would be passed from a 'CPLD Memory Manager' to a 'CPLD
Parallel Algorithm', and while that was working, another 32 bits would
be passed from the same 'CPLD Memory Manager' to the next 'CPLD
Parallel Algorithm', etc... and each 'CPLD Parallel Algorithm' when
complete would check that the other 'CPLD Memory Manager' was
available to take data and if so pass it to the memory manager, and
then asking the first memory manager for some more data.

Again, I apologise for sounding like a broken record. I'd appreciate
your thoughts for the pros and cons for something like this.

Thanks,
Nick.




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