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 30600

Article: 30600
Subject: Wanted: ISA bus implementation for Xilinx
From: ernstegon.NO@SPAM.freeze.com (Ernst Rattenhuber)
Date: 18 Apr 2001 18:46:23 GMT
Links: << >>  << T >>  << A >>
I need some kind of IP module that implements an ISA bus interface. It could be 
in the form of a "black box" or in the form of synthesizable VHDL code. I 
believe Xilinx used to have something along those lines, but it seems to have 
been discontinued. Now they only offer a "PCI Development Kit" for the PCI bus, 
and it's rather expensive too (~9000 US dollars).

My needs are not so great in terms of performance, and I'm not prepared to fork 
out that kind of money. So if someone could suggest an ISA solution that could 
be purchased for 1000 dollars or less, I'd be grateful.

I need it for the design of a PC/104 board that is to be the interface between 
measurement devices and an embedded PC. The measurement devices use a 
proprietary, synchronous serial protocol. I'm planning to implement the whole 
thing in a single FPGA, preferably a Spartan-II device.

TIA,

Ernst Rattenhuber


P.S. Email replies can be sent to the address in my header minus the obvious 
spam deterrent parts.


Article: 30601
Subject: Re: PAR single pass vs multi-pass differences
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Wed, 18 Apr 2001 19:57:59 +0100
Links: << >>  << T >>  << A >>


Utku Ozcan wrote:
> 
> BTW, from a designer point of view, I would recommend Xilinx should
> give more information what impacts for each cost table value are on
> the design. It is not declared anywhere. Ie. are cost tables from 1
> to 50 for speed and 51 till 1000 for area? It would have been
> superb. Cost table number doesn't mean anything. Therefore it would
> be the best way to run for all cost tables, ie. at least 100 runs
> for each design load.
> 
> Utku

In theory the idea is that you only run the placer passes for each cost
table & then pick the best of those, say the top 5, for a full routing
run(s).  However if the MPPR & SPPR results for a given cost table are
different then this breaks down.

Wiht my new 1G3 DDR-266 Athlon I might try to do the whole thing, place
& route for each cost table, while I'm away on a long weekend.

BTW: I think I might have been responsible for the original answers
database report or at least I may have been one of several. It took
about 2 months   of steady badgering to get Xilinx to admit there was a
problem. They then claimed to have fixed it in 2.1i SP6 - an
uninitialised variable was said to be the problem. I look back a few
months later & this had changed to say ``There may still be some
problems - wait for 3.1i''.

I have a sneaking suspicion that heuristic arguments are red herrings
here covering up what is still a bug. Its certainly true that MPPR isn't
much use if to get a good route with cost table 67 you actually have to
run full place & route from table 1,2,3, ..., 65,66,67!

Article: 30602
Subject: Re: CONTRACTORS
From: nhoxford@aol.com (Nhoxford)
Date: 18 Apr 2001 20:31:26 GMT
Links: << >>  << T >>  << A >>
Hi Mark,

I'm also looking.

Denis O'Leary

Article: 30603
Subject: Re: compression
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 19 Apr 2001 10:04:08 +1200
Links: << >>  << T >>  << A >>
Frode Vatvedt Fjeld wrote:
> 
> Jim Granville <jim.granville@designtools.co.nz> writes:
> 
> >  We are doing work on Run-Length compression using CPLD, for
> > two areas
> >
> > - Increasing apparent bandwidth
> > - Reducing storage requirements
> 
> This is exactly what I'm interested in.
> 
> > What do you want to know ?
> 
> I'd just like to know in general terms about the standard (if any)
> techniques or "algorithms" used for implementing such things in
> programmable logic.

There is no 'std' and in a PLD, you are limited to just what can be
done.
Run Length compression is very doable, as this is a table of Value +
Length,
and the Length preloads a counter.

The ECP printer port has a mode like this

In very simple RLC, the length is taken direct from the compressed data, 
but you can compress using a length pointer, that then fetches from 
a 'tiny prom' in the PLD.

We are looking into software that analyses the data to be compressed,
and
then chooses a best-fit 'tiny prom' table, that it creates along with
the 
compressed data stream.

Of course, it depends a lot on the data being handled...

-jg


-- 
======= 80x51 Tools & PLD IP Specialists  =========
= http://www.DesignTools.co.nz

Article: 30604
Subject: Re: clocking on both edges
From: Peter Alfke <palfke@earthlink.net>
Date: Thu, 19 Apr 2001 03:39:25 GMT
Links: << >>  << T >>  << A >>
Since I am being quoted, I might as well answer.
The quoted statement is a warning that you should not shoot yourself
in the foot. It is also a disclaimer that protects me from the wrath
of my synchronous brethren.
I have published, years ago, a clock double-differentiator circuit
that works reliably inside an IC, since it is kind of adaptive: If
the circuit is cold and fast, the spikes get shorter, but the
circuit also needs only shorter pulses. And vice versa. There is
tracking inside a chip. Most of the neat analog tricks that Bob
Widlar is so famous for only work due to on-chip tracking. ( How's
that for name-dropping. I actually met that famous man during my
early days at Fairchild :-).
Here is the differentiator circuit:

Incoming clock drives XOR gate, output of XOR is double-frequency
output signal.
XOR output also clocks flip-flop. Flip-flop Q drives inverter.
Inverter output drives flip-flop D, and also the other input to the
XOR.

If you want a longer pulse, make the inverter slow, ( e.g. cascade
some gates )
Yes it's a dirty trick, and the pulse length is ill-defined. And you
should not do this at multiple 100 MHz. But when there is no other
solution, this works just fine. It gets you dirty comments from the
synchronous purists though. It's your choice.

Peter Alfke
("Synchronous wherever possible. Asynchronous only when you really
know what you are doing")

luigi funes wrote:

> Hi!
> The main clock of a system is a 50 MHz, 50% duty cycle (+/-10%)
> signal.
> I have to synchronize some activities of a PLD on the rising edge
> of this signal, some on falling edge and many on both edges.
> For example, the data transfers occur on both edges and
> I have to count it, calculate CRCs, and so on.
>
> I'm tempted to do a little asynchronous trick inside the PLD to
> make a 4-6 nS pulse for each main clock edge, and use this pulse
> to clock the FFs, but I'm scared of the Peters Alfke words:
> "Asynchronous design methods may ruin your project, your
> career and your health". =:-/
>
> Which alternatives there are?
> Thanks in advance!
>
> Luigi


Article: 30605
Subject: Re: PAR single pass vs multi-pass differences
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Thu, 19 Apr 2001 14:18:15 +1000
Links: << >>  << T >>  << A >>
Utku Ozcan wrote:
> 
> Allan Herriman wrote:
> >
> > Hi,
> >
> > I'm routing a Virtex-E part, and I find that I get different routing
> > results for a particular cost table depending on whether I use single
> > pass or multi pass (the -n MPPR option) on par.
> >
> > E.g. for my current design, on cost table #1, I get a 5.830ns result
> > with single pass, but 5.925ns with multi pass, also using cost table #1.
> >
> > Question: what does par do differently, so that it gets different
> > results even though the cost table is the same?
> 
>   Program includes heuristic algorithms, ie. it doesn't find the optimal
>   but close result. Therefore at every try it might finish with different
>   result. Placer and router algorithms are NP-Complete, because P&R itself
>   is NP-Complete therefore you will never find the optimal (the only one)
>   result in a reasonable time, that's why program might cease operation
>   after a definite threshold. Decision is non-deterministic to the user.

Heuristic algorithms are deterministic on a digital machine.
This cannot explain the difference, unless they seed the random
number generator differently depending on whether this is SPPR or
MPPR.

> > Which result should I believe?
> 
>   I think each is correct.
> 
> > BTW, the 5.925ns route (MPPR) works when downloaded, and the 5.830ns
> > (SPPR) one doesn't.
> 
>   SPPR by default must have used default cost table 1, but MPPR might
>   use a different cost table.

Err, no.  I used the -t 1 option on SPPR to select cost table 1, and
the MPPR result appeared in the output file for cost table 1.
Both were definitely cost table 1.

The fact that one worked and one didn't was a red herring, as this
was caused by a completely independent tool bug.
 
> > I'm using Alliance Release 3.3.07i (par D.26), with speed files ver
> > 1.56, but I've also seen this issue on other versions.
> >
> > I've read Xilinx answer 8746, which describes a bug with similar
> > symptoms, but it says that it was fixed in version 3.1i about a year
> > ago.
> > It also says "Each MPPR result should be identical to an equivalent
> > single pass result for the same cost table."
> 
>   We must pay attention to what it has been implied with "identical".
>   Say, for example, if you get two results 4.32 ns and 3.95 ns for the
>   same initial parameters (ie. cost table) then we might say the
>   results for all those runs are identical in a definite percent
>   region (statistically).

I would have expected download files identical down to the bit level.
When I run my design through the tools again with the same EDIF and
the same command line options, I get identical download files.

I'm fairly sure this is a tool bug.

Regards,
Allan.

Article: 30606
Subject: Re: clocking on both edges
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Thu, 19 Apr 2001 05:16:34 -0000
Links: << >>  << T >>  << A >>
>Yes it's a dirty trick, and the pulse length is ill-defined. And you
>should not do this at multiple 100 MHz. But when there is no other
>solution, this works just fine. It gets you dirty comments from the
>synchronous purists though. It's your choice.

OK, I'll keep the discussion going.

Why doesn't that work at "multiple 100 MHz"?

Is there some scaling property that I'm missing?

I'm assuming that you are using fast enough silicon so that it
will work in the slow corner.



PS: I smile whenever I think of that circuit.  It's one of those
simple but neat/sneaky tricks that I wish I had thought of.

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


Article: 30607
Subject: Re: PAR single pass vs multi-pass differences
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Thu, 19 Apr 2001 08:58:37 +0300
Links: << >>  << T >>  << A >>

> I would have expected download files identical down to the bit level.
> When I run my design through the tools again with the same EDIF and
> the same command line options, I get identical download files.
> 
> I'm fairly sure this is a tool bug.
> 
> Regards,
> Allan.

  BTW have you got any chance to run 2 identical SPPRs? I mean, I wonder
  whether their results are different from each other.

  Utku

Article: 30608
Subject: Re: looking for comment on implementation
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Thu, 19 Apr 2001 07:05:50 GMT
Links: << >>  << T >>  << A >>
The DDS is normally straightforward but 240MHz is pretty fast for a Xilinx.
I just had to do a fast one so here's a couple of hints:

-The 32-bit phase accumulator can be fully pipelined by making it a group of
32 half adders, with the carries pipelined from one to the next.  Then you
need to delay the lower bits to match them with the upper bits; you can use
the SRLs for this.  This is bigger, but faster.
-The BlockRAMs will never work at 240MHz.  The clock->out time is about 3ns,
but it also takes a while to route the output to the next register.  One
trick is to use both ports of the dual-port BRAM sine lookup table.  You use
the first port on one cycle, the next on the next cycle, etc, making the
BRAM a 2-cycle path.  (You have to commutate the two output ports into one.)
But you probably can't have 2^18 precision, because that would require all
the BRAM in an extended memory part.
-There was an article in the Xilinx XCell magazine about the Cordic
algorithm, which might be applicable to you.

I think the phase ditherer is just a simple LFSR you can XOR with the LSBs.

There's got to be a way to reduce the sine lookup table size.  I wonder if
you could linearly interpolate between two points in a smaller table?  Or
maybe calculate sine using some sort of hardware Maclaurin series
calculator?

"Paul Teagle" <pteagle@chariot.net.au> wrote in message
news:3add9bf3_1@news.chariot.net.au...
> Hi,
>
> I'm looking for a very rough back-of-the-envelope estimate on the
> feasibility of implementing a complex DDS & modulator component in a FPGA.
> The relevant specs are:
>
> - operating at 240 mega complex samples/sec
>
> - 16 bit I & Q inputs to the modulator
>
> - phase accumulator 32 bits
>
> - 18 bit sine/cosine look-up accuracy, 20 bit result
>
> - 5 bit phase dither (selectable) on lsb's
>
> Assume the data is sourced on-chip and goes to other destinations on-chip.
>
> A reasonable amount of pipeling can be tolerated.
>
> We have no preference of Altera/Xilinx at the moment. SRAM based is
> required, though, as is having a fair amount of other FPGA area for other
> functions.
>
> There are several other aspects of the design (interpolators, multipliers
> etc) that I haven't mentioned, but its the DDS that I think is the most
> complicated.
>
> Any of you contractors out there want to hazard a rough order of magnitude
> of cost for developing this sort of thing, maybe in terms of hours &
> dollars, and amount of area it would consume on device XYZ ?
>
> regards,
>
> Paul Teagle
> Systems Engineer
> CAE Electronics
>
>
>
>
>
>



Article: 30609
Subject: Half-clock problem.
From: "Alan Lee" <shlee@impresstek.co.kr>
Date: Thu, 19 Apr 2001 16:54:28 +0900
Links: << >>  << T >>  << A >>
Hi,
I'm developing a board based on a virtex FPGA.
The design summary indicates that
the maximum operating frequency is about 30 MHz,
but the actual frequency in the board seems to be slower than 15 MHz.

I'm using both of clock edges (rising and falling) in my HDL code.
Is this the main cause of this result ?

Thanks.

Alan




Article: 30610
Subject: Re: Wanted: ISA bus implementation for Xilinx
From: Nial Stewart <nials@sqf.hp.com>
Date: Thu, 19 Apr 2001 09:06:01 +0100
Links: << >>  << T >>  << A >>
Ernst Rattenhuber wrote:
> 
> I need some kind of IP module that implements an ISA bus interface. It could be
> in the form of a "black box" or in the form of synthesizable VHDL code. I
> believe Xilinx used to have something along those lines, but it seems to have
> been discontinued. Now they only offer a "PCI Development Kit" for the PCI bus,
> and it's rather expensive too (~9000 US dollars).
> 
> My needs are not so great in terms of performance, and I'm not prepared to fork
> out that kind of money. So if someone could suggest an ISA solution that could
> be purchased for 1000 dollars or less, I'd be grateful.
> 
> I need it for the design of a PC/104 board that is to be the interface between
> measurement devices and an embedded PC. The measurement devices use a
> proprietary, synchronous serial protocol. I'm planning to implement the whole
> thing in a single FPGA, preferably a Spartan-II device.
> 
> TIA,
> 
> Ernst Rattenhuber


Ernst,

The ISA bus is very simple, you could probably implement one yourself
in a couple of days. It'd probably take as long to understand the operation
of any IP you can get hold of.

As far as I know it's _VERY_ slow, so you've no tight timing 
reuirements (like the PCI bus) to worry about.

Nial.

Article: 30611
Subject: wanted: dig. board with FPGA and processor
From: Steven Sanders <sanders@imec.be>
Date: Thu, 19 Apr 2001 10:07:45 +0200
Links: << >>  << T >>  << A >>
Hello masters of the digital universe!

I`m looking for a development board with following specs:

1) FPGA: Xilinx Virtex100 and beyond
2) processor: 	Speed: min. 40MHz 
		ROM: the bigger the better  
		RAM: min. 2Mbit
		Tools: ANSI C compiler
3) if possible: ethernet controller (only PHY needed)

Thanx in advance!

Steven

Article: 30612
Subject: Voltage supply reduction for low power in FPGAs.
From: Steven Derrien <sderrien@irisa.fr>
Date: Thu, 19 Apr 2001 11:02:28 +0200
Links: << >>  << T >>  << A >>
Hi,

As most people familiar with low power designs already know, there exist
a 
technique based on voltage supply reduction for  ASICS which allow 
(at the price of increased logic and routing delays) to reduce the 
overall circuit power dissipation.

I was wondering if these thechniques could be applied to modern FPGAs 
such a SPARTANII or Virtex ? Does anyone knows about this ?

Thanks 

Steven

Article: 30613
Subject: Looking for digital video to VGA RGB conversion
From: "M.S.Gaur" <msg00r@ecs.soton.ac.uk>
Date: Thu, 19 Apr 2001 10:15:28 +0100
Links: << >>  << T >>  << A >>
Hello everybody,
I am a newcomer to the FPGA programming and design area and working on a
project using Xess XSV board having Virtex fpga.
I need some help for conversion of (720 X 486) format digital video to
(640 X 480) VGA signal. One one side of the system I am getting the
decoder output and on the other side my VGA controller (being designed
on xess XSV Board) would take this data for rasterisation.
Thanks
Gaur


Article: 30614
Subject: Re: PAR single pass vs multi-pass differences
From: Allan Herriman <"allan_herriman,hates.spam"@agilent.com>
Date: Thu, 19 Apr 2001 19:17:14 +1000
Links: << >>  << T >>  << A >>
Utku Ozcan wrote:
> 
> > I would have expected download files identical down to the bit level.
> > When I run my design through the tools again with the same EDIF and
> > the same command line options, I get identical download files.
> >
> > I'm fairly sure this is a tool bug.
> >
> > Regards,
> > Allan.
> 
>   BTW have you got any chance to run 2 identical SPPRs? I mean, I wonder
>   whether their results are different from each other.

I have run 2 SPPRs on the same computer.  This resulted in identical
download files, so I can rule out transient computer problems.

I have also run an additional SPPR on a different computer, with the
same EDIF and command line arguments.
It produced a result that was different to both the SPPR and MPPR
results from the first computer.
It also worked ok in the lab, whereas the SPPR download from the first
computer had functional problems.

This implied to me that the installation of the Xilinx programs had been
corrupted on one of the computers, so I compared all the executable
files and speed files, etc. on the two computers, and they were
identical.

So why should two computers produce different results if they are
running identical programs with identical input?
I don't think that PAR uses the machine ID to seed the random number
generator.
I might have missed comparing one of the files though, or it could be a
difference in a system DLL.

Regards,
Allan.

Article: 30615
Subject: Re: Wanted: ISA bus implementation for Xilinx
From: "luigi funes" <fuzzy8888@hotmail.com>
Date: Thu, 19 Apr 2001 09:25:12 GMT
Links: << >>  << T >>  << A >>

Ernst Rattenhuber ha scritto nel messaggio
<4C01A18846D8F834.C53AD3E6B1E5410F.A773BB20C2D12EDB@lp.airnews.net>...
>I need some kind of IP module that implements an ISA bus interface. It
could be
>in the form of a "black box" or in the form of synthesizable VHDL code. I
>believe Xilinx used to have something along those lines, but it seems to
have
>been discontinued. Now they only offer a "PCI Development Kit" for the PCI
bus,
>and it's rather expensive too (~9000 US dollars).
>
>My needs are not so great in terms of performance, and I'm not prepared to
fork
>out that kind of money. So if someone could suggest an ISA solution that
could
>be purchased for 1000 dollars or less, I'd be grateful.
>
>I need it for the design of a PC/104 board that is to be the interface
between
>measurement devices and an embedded PC. The measurement devices use a
>proprietary, synchronous serial protocol. I'm planning to implement the
whole
>thing in a single FPGA, preferably a Spartan-II device.
>
>TIA,
>
>Ernst Rattenhuber
>
>
>P.S. Email replies can be sent to the address in my header minus the
obvious
>spam deterrent parts.
>

Ernst,
I think you don't need really to buy a IP module for your purpose.
The ISA bus is very easy to interface. I did a complete 16 bit interface
with a 44 pins, 32 cells CPLD.
You have only to decode the addresses, the memory R/W and the IO R/W
signals and buffering the data bus (8 or 16 bits).
The interrupt also is easy to handle. Perhaps the DMA transfer mode is
more complex, I never used it because it seems me to have no benefits
with a CPU > 386.
If you miss the ISA bus specifications, you can find easily on the web, for
example in http://www.epanorama.net

Luigi






Article: 30616
Subject: Re: looking for comment on implementation
From: "Paul Teagle" <pteagle@chariot.net.au>
Date: Thu, 19 Apr 2001 19:18:51 +0930
Links: << >>  << T >>  << A >>

Kevin Neilson <kevin_neilson@yahoo.com> wrote in message
news:i7wD6.268$cf6.37903@newsread2.prod.itd.earthlink.net...
> The DDS is normally straightforward but 240MHz is pretty fast for a
Xilinx.

my thinking as well - pretty fast,  but not absolutely TOO fast.

> I just had to do a fast one so here's a couple of hints:
>
> -The 32-bit phase accumulator can be fully pipelined by making it a group
of
> 32 half adders, with the carries pipelined from one to the next.  Then you
> need to delay the lower bits to match them with the upper bits; you can
use
> the SRLs for this.  This is bigger, but faster.

One thing I forgot to mention was that the frequency value stays constant,
but I'm not sure if this helps.

> -The BlockRAMs will never work at 240MHz.  The clock->out time is about
3ns,
> but it also takes a while to route the output to the next register.  One
> trick is to use both ports of the dual-port BRAM sine lookup table.  You
use
> the first port on one cycle, the next on the next cycle, etc, making the
> BRAM a 2-cycle path.  (You have to commutate the two output ports into
one.)
> But you probably can't have 2^18 precision, because that would require all
> the BRAM in an extended memory part.

> -There was an article in the Xilinx XCell magazine about the Cordic
> algorithm, which might be applicable to you.
>

Ray Andraka's area, I think.

> I think the phase ditherer is just a simple LFSR you can XOR with the
LSBs.
>
> There's got to be a way to reduce the sine lookup table size.  I wonder if
> you could linearly interpolate between two points in a smaller table?  Or
> maybe calculate sine using some sort of hardware Maclaurin series
> calculator?

Perhaps a coarse/fine table:

sin(a+b) = sin(a)cos(b) + sin(b)cos(a)

where a = 9 bits coarse angle (say 0 to 360/(2^8)) = 0.7 degrees
          b = 9 bits fine angle (say 0 to 0.7/(2^9)) = 1.37millidegrees

Thus two, 512 word look-up tables, rather than a single 262k table, to get
the same precision...Dual port to access the sine & cosine simultaneously,
with any caveats for look-up speed.

Maybe some complication to put the angle into an (a+b) format first, but how
hard can it be :-)

Obviously, we'll need a couple more multipliers & adders, but from the sound
of it, the Virtex-II multipliers will cope with the speed (?)

Time to start reviewing the device specs.

Thanks for the input so far.

regards,

Paul T.



Article: 30617
Subject: Re: clocking on both edges
From: "Hans Summers" <HansSummers@HotMail.Com>
Date: Thu, 19 Apr 2001 11:51:04 +0100
Links: << >>  << T >>  << A >>

"Peter Alfke" <palfke@earthlink.net> wrote in message
news:3ADE5DDC.E6BD129E@earthlink.net...
[...]
>
> Incoming clock drives XOR gate, output of XOR is double-frequency
> output signal.
> XOR output also clocks flip-flop. Flip-flop Q drives inverter.
> Inverter output drives flip-flop D, and also the other input to the
> XOR.
>
> If you want a longer pulse, make the inverter slow, ( e.g. cascade
> some gates )

I see how this works.

To double a clock pulse I have previously used a similar circuit where a
74LS86 (Quad XOR gate) was clocked at 5.333MHz giving an output of 10.666MHz
(http://www.hanssummers.com/computers/newz80/circuit/circuit.htm#P2). In
this circuit the incoming clock drives one input of the XOR directly, the
other XOR input is driven by the same incoming clock but via an inverter. In
my case the inverter consists of the other 3 XOR gates in the chip. Only one
inverter would make the width of the output pulse too short, I had some
trouble when I tried it.

Is your circuit better than this one (e.g. more stable) or another way to
acheive the same result?

------------------
Hans Summers
http://www.HansSummers.Com



Article: 30618
Subject: Re: compression
From: Frode Vatvedt Fjeld <frodef@acm.org>
Date: 19 Apr 2001 14:40:56 +0200
Links: << >>  << T >>  << A >>
Jim Granville <jim.granville@designtools.co.nz> writes:

> [..] Of course, it depends a lot on the data being handled...

Ok, thanks for the help.

-- 
Frode Vatvedt Fjeld

Article: 30619
Subject: Jobs@ ASIC / FPGA / VLSI designers needed - Canada
From: "PROCOM" <derekw@procom.ca>
Date: Thu, 19 Apr 2001 09:41:17 -0400
Links: << >>  << T >>  << A >>
Our client is the leading provider of highly integrated silicon solutions
that enable broadband digital transmission of voice, video, and data. Using
proprietary technologies and advanced design methodologies, the company
designs, develops and supplies integrated circuits for a number of the most
significant broadband communications markets, including the markets for
cable set-top boxes, cable modems, high-speed local, metropolitan and wide
area networks, home networking, Voice over Internet Protocol (VoIP),
residential broadband gateways, direct broadcast satellite and terrestrial
digital broadcast, optical networking, digital subscriber lines (xDSL) and
wireless communications.

They are currently seeking ASIC Designers with the following...

Required Skills and Experiences:

BSEE or equivalent; MSEE preferred, plus 5+ years' of VLSI hardware design
experience.
Position requires working knowledge of Verilog and Synopsys.
Experience with back-end CAE, layout tools, 3D, video, and DSP is a plus.


Responsibilities:

Responsibilities include: definitions of the molecules specifications based
on the system specification; RTL development and debugging, test bench
development; design validation as part of an overall system, system
integration; synthesis of the RTL at a certain clock speed; Implementation
of the test strategy, scan insertion, ATPG test vectors generation.


PROCOM: Established in 1978, Professional Computer Consultants Group Ltd.
(Procom) is a national leader in the provision of Computer personnel on a
contract
and full-time basis. Our clients are comprised of the largest national and
international corporations that utilize technical resources extensively
across a wide range of disciplines. In the Financial Post (March 1999)
Procom was ranked as the 6th largest professional Services Company in
Canada. In November of 1999, Procom was named a Regional finalist in Canada'
s 50 Best Managed Private companies. Our track record is proven with more
than 180 consultants servicing Ottawa's high tech community and more than
1600 Procom consultants currently on assignment throughout. North America.
For further information on this and other opportunities please visit our web
site at www.procom.ca.

Interested candidates are invited to forward their resumes or questions in
confidence to:



Derek Weber
PROCOM

300 March Rd Suite 600
Kanata, Ontario
K2K-2E2
613-270-9339 x231
613-270-9449 (FAX)

derekw@procom.ca
www.procom.ca





Article: 30620
Subject: Senior ASIC Designers Needed - Canada
From: "PROCOM" <derekw@procom.ca>
Date: Thu, 19 Apr 2001 09:41:43 -0400
Links: << >>  << T >>  << A >>

Our client is the world leader in sales of communications semiconductors.
They  design, develop and manufacture optoelectronic components for
communications networks, and integrated circuits for use in a broad range of
communications and computer equipment.

They sell there products globally to the leading manufacturers of
communications and computer equipment.

There optoelectronic components transmit, process, change, amplify and
receive light that carries data and voice traffic over optical networks.
They provide optoelectronic components for use in both submarine and
terrestrial networks, including high-speed transport networks, metropolitan
networks, cable television networks and data communications networks.

Our client offers integrated circuits, or chips, for a broad range of
communications networks and computer equipment. Our integrated circuits are
designed to perform various functions, such as processing electronic
signals, controlling electronic system functions and processing and storing
data. We also offer wireless local area networking products, which
facilitate the transmission of data and voice signals within a localized
area without cables or wires.

As a Senior ASIC Design Engineer, this individual will lead a dedicated team
designing very large (1M+gates), high speed (80+MHz) and complex ASICs
targeting leading-edge SONET/SDH Datacom (ATM, POS) and Telecom (ADM, TM)
applications with 5+ years experience. Responsibilities will include system
level specification, architecture, documentation, project management and
development team leadership.  As a Senior ASIC Design Engineer, this
individual will lead a small team (4-6) of talented Engineers in all phases
of the ASIC development flow (design in RTL level HDL, verification,
synthesis, DFT insertion, floor-planning and timing analysis) using
UNIX-based CAD tools (eg: Verilog, Synopsys, static timing, formal
checking).  Other responsibilities include working with UNIX, Emacs, RCS and
mentoring of junior Engineers and customer interaction.

This individual must be legally employable in Canada and communicate
fluently in English.  This position is a permanent full-time reporting to
the ASIC Department.


PROCOM: Established in 1978, Professional Computer Consultants Group Ltd.
(Procom) is a national leader in the provision of Computer personnel on a
contract
and full-time basis. Our clients are comprised of the largest national and
international corporations that utilize technical resources extensively
across a wide range of disciplines. In the Financial Post (March 1999)
Procom was ranked as the 6th largest professional Services Company in
Canada. In November of 1999, Procom was named a Regional finalist in Canada'
s 50 Best Managed Private companies. Our track record is proven with more
than 180 consultants servicing Ottawa's high tech community and more than
1600 Procom consultants currently on assignment throughout. North America.
For further information on this and other opportunities please visit our web
site at www.procom.ca.


Derek Weber
PROCOM

300 March Rd Suite 600
Kanata, Ontario
K2K-2E2
613-270-9339 x231
613-270-9449 (FAX)

derekw@procom.ca
www.procom.ca













Article: 30621
Subject: Re: PAR single pass vs multi-pass differences
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Thu, 19 Apr 2001 17:27:17 +0300
Links: << >>  << T >>  << A >>
> I have run 2 SPPRs on the same computer.  This resulted in identical
> download files, so I can rule out transient computer problems.
>
> I have also run an additional SPPR on a different computer, with the
> same EDIF and command line arguments.
> It produced a result that was different to both the SPPR and MPPR
> results from the first computer.
> It also worked ok in the lab, whereas the SPPR download from the first
> computer had functional problems.
>
> This implied to me that the installation of the Xilinx programs had been
> corrupted on one of the computers, so I compared all the executable
> files and speed files, etc. on the two computers, and they were
> identical.
>
> So why should two computers produce different results if they are
> running identical programs with identical input?
> I don't think that PAR uses the machine ID to seed the random number
> generator.
> I might have missed comparing one of the files though, or it could be a
> difference in a system DLL.

Very tight observation, thank you very much for your comments.

Then machine time might be different? Maybe tools use machine time for
seed to obtain "random" behavior. Ok, you are using PC, probably it is
similar under UNIX. Well, anyway, these things will be unanswered questions
for a while then!

> Regards,
> Allan.

Utku


Article: 30622
Subject: Re: Voltage supply reduction for low power in FPGAs.
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 19 Apr 2001 09:03:12 -0700
Links: << >>  << T >>  << A >>
Steven,

If you lower the voltage to the FPGA, it will either trip the power on reset
theshold voltage, and start over, or it will just slow down until it trips
and resets.

You can always choose to operate anywhere inside the recommended operating
conditions limits, and expect the device to perform to specifications.

You may also operate anywhere inside the absolute maximum ratings and expect
thge device to function, but it may not meet timing, or some other
specification.

The smaller Spartan II devices XC2S15 and XC2S30 parts are measuring around
20 mA for turning on at room temperature, typical, and the quiescent current
is a little less (2.5 V Vccint, 3.3 V Vcco's).  We will have much better
data once we see some process corners.

Virtex II 2V40 is at about 24 mA to turn on, and about 8 mA in the power
down mode at room temperature, typical (1.5 V Vccint, 3.3 V Vcco's).

What do you feel is "low" power?

Austin

Steven Derrien wrote:

> Hi,
>
> As most people familiar with low power designs already know, there exist
> a
> technique based on voltage supply reduction for  ASICS which allow
> (at the price of increased logic and routing delays) to reduce the
> overall circuit power dissipation.
>
> I was wondering if these thechniques could be applied to modern FPGAs
> such a SPARTANII or Virtex ? Does anyone knows about this ?
>
> Thanks
>
> Steven


Article: 30623
Subject: Re: clocking on both edges
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 19 Apr 2001 09:45:13 -0700
Links: << >>  << T >>  << A >>
Why my warning about >100 MHz ? Mainly paranoia.
In order to be reliable, the spike should not be too short, and at >100 MHz
there are not so many ns.
Fundamentally, I like to have plenty of timing margin for tricks like this. At
the 50 MHz, a 5 ns spike would be just fine.
But everything scales.
So it's really paranoia and fear of the synchronous zealots.

Thanks for the friendly compliment.

Peter Alfke
===========================
Hal Murray wrote:

> >Yes it's a dirty trick, and the pulse length is ill-defined. And you
> >should not do this at multiple 100 MHz. But when there is no other
> >solution, this works just fine. It gets you dirty comments from the
> >synchronous purists though. It's your choice.
>
> OK, I'll keep the discussion going.
>
> Why doesn't that work at "multiple 100 MHz"?
>
> Is there some scaling property that I'm missing?
>
> I'm assuming that you are using fast enough silicon so that it
> will work in the slow corner.
>
> PS: I smile whenever I think of that circuit.  It's one of those
> simple but neat/sneaky tricks that I wish I had thought of.
>
> --
> These are my opinions, not necessarily my employeers.  I hate spam.


Article: 30624
Subject: Re: clocking on both edges
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 19 Apr 2001 09:57:00 -0700
Links: << >>  << T >>  << A >>
The difference is that "your" circuit is open loop, while my circuit is closed
loop.

When the input level changes, the output goes High. This rising edge toggles the
flip-flop, its Q gets inverted, and that shuts off the double-frequency clock
spike.
So the clock spike must first be successful in triggering the flip-flop before
it can be terminated. That is a safer mechanism than the XORing of a signal and
a delayed version of itself. Which of course works also, provided the delay is
long enough.

Greetings
Peter Alfke, Xilinx Applications

Hans Summers wrote:

> Is your circuit better than this one (e.g. more stable) or another way to
> acheive the same result?
>
> ------------------
> Hans Summers
> http://www.HansSummers.Com




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