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 34150

Article: 34150
(removed)


Article: 34151
Subject: Re: Xilinx foundation multi-pad pin assignments
From: dpariseau@compuserve.com (David Pariseau)
Date: 15 Aug 2001 10:36:04 -0700
Links: << >>  << T >>  << A >>
> You should be able to do this in the UCF file. You will need
> to know the exact name of each signal though. It will look
> something like this:
> 
> net "bus_name[0]"  loc=a12;
> net "bus_name[1]"  loc=b12;
> net "bus_name[2]"  loc=c8;
> net "bus_name[3]"  loc=d5;
> 
> One way to get the final output names (might not have "[ ]" ) is
> to run the design without the "loc" constraints, bring up the result
> in the FPGA editor, and then poke around the I/O cells to see
> what the final names look like. The .PAD file is probably also
> useful.
> 
> Here are two lines from one of my .PAD files:
> 
> | io_c13 (L01P_1)                                | OUTPUT    | C13    | LVTTL    | 12       | SLOW |          |
> | io_d12 (L02P_1)                                | OUTPUT    | D12    | LVTTL    | 12       | SLOW |          |
> 
> Here are the two lines from my .UCF FILE
> 
> NET io_d12    LOC = D12;
> NET io_c13    LOC = C13;
> 
> While not a bus, it at least shows the syntax
> 
> Philip
> 

Thanks for the reply!  I may have to do something like that.  I did
get another reply however that I wanted to share with anyone else that
may have to do this in the future.  Thanks again.

Dave.

>Select the Hierarchy->Hierarchy Push tool and click on the IPAD16
symbol.
This will bring up a window in which all the individual IPADs are
visible.
Then you can right-click on each IPAD and select the Symbol Properties
entry in the pop-up menu that appears.  Then place the pin assignment
in
the Parameters window.

Article: 34152
Subject: Re: Reconfigurable Computational Accelerator
From: Luke Roth <roth@harp.cse.psu.edu>
Date: Wed, 15 Aug 2001 14:00:15 -0400
Links: << >>  << T >>  << A >>
	Alternatively, as part of my research (I'm a grad student at Penn
State) we're building an FPGA accelerator card which resides on the SDRAM
memory bus.  Much faster than PCI (up to 133MHz x 64 bits vs 33MHz x 32
bits) and _much_ lower latency.  Our current board has a Virtex XCV300 and
64MB of SDRAM, sufficient for quite a few interesting applications.
	There are some limitations with this approach - for example, there
are no nice interrupt facilities as available on the PCI bus - but other
than that it seems like a great solution.  We're testing our first board
now, it will interesting to see what kind of performance we can acheive
with this method.  If you're interested in some more (admittedly a bit
outdated) information, check out www.cedcc.psu.edu/smartdimm/
	Luke Roth

On Wed, 15 Aug 2001, Dave Feustel wrote:

> I've been thinking about the i/o interface obstacle that exists between
> cpu and pci-bus mediated fpga accelerators for a couple of days now.
> I have come to the conclusion that the way to have *really* fast
> fpga accelerators is to put a hardwired cpu on the fpga chip along
> with the accelerator logic and make the entire application run
> directly from the fpga. You now can get fpgas with ARM, Powerpc
> and or other custom cpus preprogrammed into them and still have
> lots of room for your accelerator logic. IP cores for almost every
> commonly used peripheral are available to be incorporated onto
> the fpga chip - leave off the interfaces you don't need.
> Put the whole thing on a PCI card and plug it into your pc to
> make development easier(download through the pci bus).
>
> "Mike Butts" <mbutts@realizer.com> wrote in message news:3B758FB0.B98CA76A@realizer.com...
> > Dave Feustel wrote:
> > > The real short version is
> > > that the PCI bus interface is so slow relative to the
> > > speeds of the cpu and accelerator that it usually
> > > isn't worth adding an accelerator if the interface
> > > is via the PCI bus.
> >
> > This is often, but not necessarily true.  Accelerator architecture
> > totally depends on your application.  This is exactly what Philip
> > meant by "how long should a piece of string be".  Not ridicule,
> > just maybe a little drier wit than we're used to...
> >
> > If your application depends on lots of back-and-forth
> > between the host and the card in its core kernel, PCI is usually
> > a barrier.  Many early research projects in this field found this
> > out the hard way.  It's not the bandwidth that matters in such
> > cases, it's the latency, the round-trip time for a single operation.
> >
> > PCI, especially as implemented in modern PCs and workstations,
> > can be very bad at that.  Mark Shand gave an excellent and
> > most useful paper about this at FCCM '97, that anyone using PCI
> > must study:
> > Laurent Moll and Mark Shand. Systems performance measurement on
> > PCI Pamette. In FPGAs for Custom Computing Machines
> >      (FCCM'97). IEEE, April 1997.
> > http://www.research.compaq.com/SRC/staff/shand/bib.html
> >
> > If, on the other hand, your app is a self-contained kernel that
> > grinds away mostly on its own, PCI can be fine.  Often signal
> > processing apps are like this, with the signal I/O direct to
> > the card.
> >
> > I believe a very big win for reconfigurable computing is for
> > apps that demand lots of parallel memory bandwidth, since the
> > processor-memory bottleneck is so fundamental to conventional
> > computing.  I'm working with a project at Oregon Graduate Institute
> > lately to develop a neural network accelerator.  In our case, it's all
> > about memory bandwidth.  I/O to/from the host is orders of
> > magnitude less.  We're planning a PCI card with as many SDRAM DIMMs
> > as we can hook up to some FPGAs for them to grind away on matrix-
> > vector multiplies in parallel at 100 MHz.  PCI will just control
> > and program the card, and feed inputs and collect results at a
> > lazy and latency-insensitive pace.
> >
> > So tell us more about your application, and maybe we can give you
> > better advice.
> >
> >    --Mike
>
>
>


Article: 34153
Subject: Re: Internal clock skew when using DLL
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Wed, 15 Aug 2001 14:03:02 -0400
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
news:3B7BF014.2A82A301@gmx.de...
> Jamie Sanderson schrieb:

I don't know how to "schrieb"... ;)

> We discussed this some time ago. Conclusion was.
>
> Use the DLL to double the clock BUT dont transfer datas from one clock
> domain to the other on the same clock edge. Because when the clock nets
> are loaded very unequal, skew can be an issue, even with the DLL.
> This is a advice from Ray Andraka. He can explain this more detailed.

Makes sense to me. I was hoping the software would do better than assume
zero skew introduced by the DLL. Peter Alfke emailed me with similar advice.
I think what I'll do is use the CLK2X180 output, instead of CLK2X. I think
that allows me to use rising edge clocks everywhere, while providing a
quarter clock period of setup/hold between the clock domains.

Thanks!
Jamie



Article: 34154
Subject: Re: Internal clock skew when using DLL
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Wed, 15 Aug 2001 14:06:36 -0400
Links: << >>  << T >>  << A >>
"Jamie Sanderson" <jamie@nortelnetworks.com> wrote in message
news:9ledgn$gb5$1@bcarh8ab.ca.nortel.com...

> I think what I'll do is use the CLK2X180 output, instead of CLK2X. I think
> that allows me to use rising edge clocks everywhere, while providing a
> quarter clock period of setup/hold between the clock domains.

Hmm, this gives me a mapper error

ERROR:MapLib:326 - DCM symbol "dcm0" (output signal=slow2x_clk) CLKFB is not

driven by the CLK0 or CLK2X pin of the same DCM.

Errors found during the mapping phase. Output files will not be written.

That's annoying... Back to the drawing board.




Article: 34155
Subject: Re: Building a clock out of a PLD
From: Ken Smith <kensmith@rahul.net>
Date: 15 Aug 2001 18:25:12 GMT
Links: << >>  << T >>  << A >>

I've done this with other types of PLDs.  You need to make 2 inverters in
the PAL.  The non-inverted output connects to the input via a capacitor,
or a resistor and capacitor in series.  The inverting output connects via
a resistor to the input.  It is the same circuit you make from a CMOS
logic gate.  You take the clock from the second inverter's output.

In article <140820011643075782%penfold@deadbeat.edu>,
Eric Inazaki  <penfold@deadbeat.edu> wrote:
>I have a PLD circuit which requires a clock signal.  I'm thinking it'd
>be really nice if I could use some of the otherwise unused gates (along
>with a cap and a couple of  resistors) to generate the clock.  Is this
>a bad idea, doomed to failure or is this sort of thing done all the
>time?  With respect to timing circuits in general, can PLDs be used in
>place of discreet logic gates?  In this particular case I'm using a
>Lattice ispLSI1016E.  
>
>thanks,
>eric


-- 
--
kensmith@rahul.net   forging knowledge


Article: 34156
Subject: Re: Development Boards for FPGA based Application
From: "Walt" <sales@southwestsoftware.com>
Date: Wed, 15 Aug 2001 19:12:03 GMT
Links: << >>  << T >>  << A >>
We have a development board with two Spartan II FPGAs on it, used for
wireless systems development using a Texas Instruments DSP Starter Kit.  It
provides a total development environment at a very reasonable price..

For more information, checkout www.southwestsoftware.com/sw6x100.htm

Regards,

Walt


"Ali" <aelmousa@yahoo.com> wrote in message
news:4eede02c.0108140256.6fd35d23@posting.google.com...
> Hello All,
>
> I am looking for reasonably priced development boards that use FPGAs.
> The boards should be for application development and not for testing
> purposes. They should use the PCI bus interface in a PC. I am not
> interested in going into the details of programming the PCI interface
> if an FPGA is used for that purpose.
>
> It is preferable to have parts of the PCB board available for in-house
> circuit additions also. Memory subsytem is not very important on the
> board.
>
> Any help with knowledge of availability of such boards, vendor
> addresses, web pointers, prices etc will be greatly appreciated.
>
> Thank you.
>
> Ali



Article: 34157
Subject: fpga with the smallest i/o setup and hold requirement
From: adjohan@yahoo.com (Adrianus)
Date: 15 Aug 2001 13:22:53 -0700
Links: << >>  << T >>  << A >>
Hi,

I'm looking for a device that has very small setup and hold
requirement. I'm trying to use this device to capture a 250 MHz DDR
bus with single ended HSTL level. Ideally, I would like the device to
require not more than 300 ps of setup and hold window. My gross data
window is 2ns, but after the driver clk to data skew, edge rate
effect, board effect, etc... I don't have much margin left.

It seems to me that Xilinx Virtex II is pretty decent, it is spec'ed
at 690 ps of setup and 0 hold. Does anyone know any other device
that's better??

Any help would be greatly appreciated!

THanks,
Adrianus

Article: 34158
Subject: DPLL frequency synthesis
From: "Pierre de Vos" <pierre.devos@webmail.co.za>
Date: Wed, 15 Aug 2001 22:38:13 +0200
Links: << >>  << T >>  << A >>
Hi,

I need to to generate a synthesised frequency of Fin * 65536 where  45Hz <
Fin < 65Hz.  Does anybody know of a VHDL core that can do this.  I have
FLEX6016, reference CLK=50MHz.

Regards
Pierre





Article: 34159
(removed)


Article: 34160
(removed)


Article: 34161
(removed)


Article: 34162
(removed)


Article: 34163
Subject: Major performance problem with Modelsim
From: fr_a69@hotmail.com (Frederic Antonin)
Date: 15 Aug 2001 14:10:31 -0700
Links: << >>  << T >>  << A >>
I discover a major performance problem with Modelsim

When your simulating a design using a ram the memory array is usually
describe that way in verilog:

reg [mem_with - 1 :0] my_memory [0: mem_deep - 1];

If your memory deep is more than a couple to hundred (mine is 521k for
example)
you can't even display a single memory location (16 bit) without
having all your system ressources used and all you ram used (i have
1Gb or ram and it use all)

If you'r lucky and patient and you PC doesn't crash when you drag your
memory location from the signal window to the wave window don't think
your done.
Running a simulation is just impossible the sumulator just rumm
forever to do nothing.

I think the worste about it is that I contact them to report the
problem but they don't seems to care about it.

If any of you know a "smart" simulator that is able to handle that
kind of case let me know.

Regards

Fred

Article: 34164
Subject: Re: Building a clock out of a PLD
From: Eric Inazaki <einazaki@mac.com>
Date: Wed, 15 Aug 2001 16:38:42 -0500
Links: << >>  << T >>  << A >>
Do you recall what kind of PLD you used?  Also, what frequency were
you running?

Thanks,
eric


On 15 Aug 2001 18:25:12 GMT, Ken Smith <kensmith@rahul.net> wrote:

>
>I've done this with other types of PLDs.  You need to make 2 inverters in
>the PAL.  The non-inverted output connects to the input via a capacitor,
>or a resistor and capacitor in series.  The inverting output connects via
>a resistor to the input.  It is the same circuit you make from a CMOS
>logic gate.  You take the clock from the second inverter's output.
>
>In article <140820011643075782%penfold@deadbeat.edu>,
>Eric Inazaki  <penfold@deadbeat.edu> wrote:
>>I have a PLD circuit which requires a clock signal.  I'm thinking it'd
>>be really nice if I could use some of the otherwise unused gates (along
>>with a cap and a couple of  resistors) to generate the clock.  Is this
>>a bad idea, doomed to failure or is this sort of thing done all the
>>time?  With respect to timing circuits in general, can PLDs be used in
>>place of discreet logic gates?  In this particular case I'm using a
>>Lattice ispLSI1016E.  
>>
>>thanks,
>>eric
>
>
>-- 


Article: 34165
Subject: Re: Building a clock out of a PLD
From: jmrice@ntlworld.com (Martin Rice)
Date: 15 Aug 2001 14:47:04 -0700
Links: << >>  << T >>  << A >>
Eric Inazaki <penfold@deadbeat.edu> wrote in message news:<140820011643075782%penfold@deadbeat.edu>...
> I have a PLD circuit which requires a clock signal.  I'm thinking it'd
> be really nice if I could use some of the otherwise unused gates (along
> with a cap and a couple of  resistors) to generate the clock.  Is this
> a bad idea, doomed to failure or is this sort of thing done all the
> time?  With respect to timing circuits in general, can PLDs be used in
> place of discreet logic gates?  In this particular case I'm using a
> Lattice ispLSI1016E.  
> 
> thanks,
> eric

I've used a two-inverter circuit oscillator, using gates inside a
Coolrunner (Xilinx) PLD.  The circuit goes:
inverter between nodes A and B
inverter between nodes B and C
100nF between C and A
10k between A and B

I got nice square waves at B and C; exponential decay at A, 1.7ms
period.

Unfortunately, the signal generated was useless as a clock for further
circuits inside the CPLD!  Not sure why... the square waves had nice
clean edges.  I guess the chip didn't like the slow edges at A.  I
think your inverter/buffer circuit would have the same problem since
there is an exponential decay waveform at the input to the buffer. 
BTW, I think your circuit would work (in non-CPLD implementation) if
you replace R2 with short.

I ended up using 555.  R from output to threshold/trigger; 
C from threshold/trigger to GND.  Gives nice output.  Rarely seen this
simple circuit published.  Only drawback I know is that output doesn't
go rail to rail for bipolar version (but does for CMOS).

Have fun.

Article: 34166
Subject: Re: Building a clock out of a PLD
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Wed, 15 Aug 2001 15:47:25 -0600
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> 
> Martin Rice wrote:
> >
> > Eric Inazaki <penfold@deadbeat.edu> wrote in message news:<140820011643075782%penfold@deadbeat.edu>...
> > > I have a PLD circuit which requires a clock signal.  I'm thinking it'd
> > > be really nice if I could use some of the otherwise unused gates (along
> > > with a cap and a couple of  resistors) to generate the clock.  Is this
> > > a bad idea, doomed to failure or is this sort of thing done all the
> > > time?  With respect to timing circuits in general, can PLDs be used in
> > > place of discreet logic gates?  In this particular case I'm using a
> > > Lattice ispLSI1016E.
> > >
> > > thanks,
> > > eric
> >
> > I've used a two-inverter circuit oscillator, using gates inside a
> > Coolrunner (Xilinx) PLD.  The circuit goes:
> > inverter between nodes A and B
> > inverter between nodes B and C
> > 100nF between C and A
> > 10k between A and B
> >
> > I got nice square waves at B and C; exponential decay at A, 1.7ms
> > period.
> >
> > Unfortunately, the signal generated was useless as a clock for further
> > circuits inside the CPLD!  Not sure why... the square waves had nice
> > clean edges.  I guess the chip didn't like the slow edges at A.  I
> > think your inverter/buffer circuit would have the same problem since
> > there is an exponential decay waveform at the input to the buffer.
> 
>  What looks 'clean' to even a 100Mhz Scope may not be a clean-enough
> clock signal, especially if it comes from a slow-slew oscillator!
> 
> > BTW, I think your circuit would work (in non-CPLD implementation) if
> > you replace R2 with short.
> 
>  The second R is not needed for timing, what it does is provide
> overdrive
> protection, and also improves stability.
>  Without it, you try and drive nominally 50% beyond the rails on the
> RC node.
>  We have used 1R, and two equal C's to avoid both the overdrive,
> and the very 'sensistive' node that an R.R.C oscillator gives.
>  But you take a hit in absolute tolerance, as C's are lower tolerance
> than R's.
> 
>  A good challenge for students, is to get them to design a LR oscillator
> !
> 
> 
> > I ended up using 555.  R from output to threshold/trigger;
> > C from threshold/trigger to GND.  Gives nice output.  Rarely seen this
> > simple circuit published.
> 
>  Probably because of
> a) The nasty loads often seen on 555 lash-ups :-)
> b) The Bipolar 555's did not go rail-rail on the output
>    so Freq tolerance is not as good.
> 
>  You are right tho, a single RC two terminal config works,
> ( same as HC14/40106 circuit) and well with a CMOS version
> - which are just ~25c.
> 
>  Because C555's are 'everywhere', they are a better education/prototype
> choice than TinyLogic, but I have seen designers swear they will never
> ship anything with a 555 in it :-)
> 
> > Only drawback I know is that output doesn't
> > go rail to rail for bipolar version (but does for CMOS).
> 
> -jg

I would just use the good old fashioned Schmitt triggers.
-- 
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.

Article: 34167
Subject: Re: fpga with the smallest i/o setup and hold requirement
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 15 Aug 2001 15:13:15 -0700
Links: << >>  << T >>  << A >>
Adrianus,

Virtex II is (less than) 300 ps for the DDR setup and hold in the clock
forwarded case using the DCM.  The DDR clock forwarded interface requires
a combination of system features to be used, and we just finished
characterizing the combinations.

For the non-clock forwarded DDR case, the larger numbers apply.

We have released a DDR spec available to the FAE's to cover these
interfaces.

Single ended HSTL is another matter.  250 MHz is 500 Mb/s, and HSTL isn't
the best interface to use at these frequencies.  Signal integrity is
going to be a PhD thesis, and coupling, noise, and jitter will be a tough
system design road to travel down.

I suggest you run some simple IBIS simulations to look at duty cycle, and
rise and fall times of the HSTL standards at this frequency.

Austin
Xilinx FPGA Lab

Adrianus wrote:

> Hi,
>
> I'm looking for a device that has very small setup and hold
> requirement. I'm trying to use this device to capture a 250 MHz DDR
> bus with single ended HSTL level. Ideally, I would like the device to
> require not more than 300 ps of setup and hold window. My gross data
> window is 2ns, but after the driver clk to data skew, edge rate
> effect, board effect, etc... I don't have much margin left.
>
> It seems to me that Xilinx Virtex II is pretty decent, it is spec'ed
> at 690 ps of setup and 0 hold. Does anyone know any other device
> that's better??
>
> Any help would be greatly appreciated!
>
> THanks,
> Adrianus


Article: 34168
Subject: Slowing PCI for FPGA
From: Joey Oravec <joey@sun.science.wayne.edu>
Date: 15 Aug 2001 22:23:12 GMT
Links: << >>  << T >>  << A >>
Hi, surely somebody else has run into this before.

I am doing a prototype with a PCI interface and there isn't a prayer of
making it work at 25mhz bus transfer (my slowest machine available)
without a lot of effort. What would you do to easily slow things down? I
know DINI group has a card for $600 that will halve the PCI clock and
another for $3k which is more flexible. There's PCI-PCI bridge IP
available but that's also expensive.

Unfortunately I'm cheap and I'm thinking there must be a better
inexpensive solution. Any thoughts?

-- 
  O..O    Arcade machine collection:
 (----)        http://www.science.wayne.edu/~joey/arcade/
( >__< )  IRC - EFNet #rgvac: demigod2k
^^ ~~ ^^

Article: 34169
Subject: Multilinx problem
From: Quiet Desperation <a@b.invalid>
Date: Wed, 15 Aug 2001 16:54:10 -0700
Links: << >>  << T >>  << A >>
I have a small board with a Virtex-E and XC18V01 PROM soldered to the
board. The JTAG port is connected to the PROM only.

The JTAG Programmer software talks to the Multilinx pod via serial port
1, and that works. The software can figure out the JTAG chain and the
PROM chip automatically. I can then get the chip ID, signature and run
an empty check with no problem, so the Multilinx hardware and my PWB
seem OK.

When I load up an MCS file created by promgen (Yes, I selected the
correct package for the XC18V01), it all falls apart. I get "JTAG chain
not defined correctly" and "check BSDL file" warnings and whatnot. I
can't even do the chip ID and empty check as I could before. :-\

Everything is fine until I incorporate the PROM file. Could there be
some sort of disconnect between promgen and the JTAG programmer? It
almost seems as if the part data in the MCS file is wrong, and fouls up
the chain definition in the JTAG Programmer.

To generate the MCS file, I used:

promgen -w -u 0 -x xc18v01 -p mcs bitfile.bit

I think it's -p for the file type... I forget.

??? Thanks very much in advance if anyone has an idea.

-- 
- Quiet Desperation -
"The mass of men lead lives of quiet desperation." -- Henry David Thoreau

Article: 34170
Subject: Re: Building a clock out of a PLD
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 16 Aug 2001 11:55:35 +1200
Links: << >>  << T >>  << A >>
Martin Rice wrote:
> 
> Eric Inazaki <penfold@deadbeat.edu> wrote in message news:<140820011643075782%penfold@deadbeat.edu>...
> > I have a PLD circuit which requires a clock signal.  I'm thinking it'd
> > be really nice if I could use some of the otherwise unused gates (along
> > with a cap and a couple of  resistors) to generate the clock.  Is this
> > a bad idea, doomed to failure or is this sort of thing done all the
> > time?  With respect to timing circuits in general, can PLDs be used in
> > place of discreet logic gates?  In this particular case I'm using a
> > Lattice ispLSI1016E.
> >
> > thanks,
> > eric
> 
> I've used a two-inverter circuit oscillator, using gates inside a
> Coolrunner (Xilinx) PLD.  The circuit goes:
> inverter between nodes A and B
> inverter between nodes B and C
> 100nF between C and A
> 10k between A and B
> 
> I got nice square waves at B and C; exponential decay at A, 1.7ms
> period.
> 
> Unfortunately, the signal generated was useless as a clock for further
> circuits inside the CPLD!  Not sure why... the square waves had nice
> clean edges.  I guess the chip didn't like the slow edges at A.  I
> think your inverter/buffer circuit would have the same problem since
> there is an exponential decay waveform at the input to the buffer.

 What looks 'clean' to even a 100Mhz Scope may not be a clean-enough
clock signal, especially if it comes from a slow-slew oscillator!

> BTW, I think your circuit would work (in non-CPLD implementation) if
> you replace R2 with short.

 The second R is not needed for timing, what it does is provide
overdrive
protection, and also improves stability.
 Without it, you try and drive nominally 50% beyond the rails on the
RC node.
 We have used 1R, and two equal C's to avoid both the overdrive, 
and the very 'sensistive' node that an R.R.C oscillator gives. 
 But you take a hit in absolute tolerance, as C's are lower tolerance
than R's.

 A good challenge for students, is to get them to design a LR oscillator
!

 
> I ended up using 555.  R from output to threshold/trigger;
> C from threshold/trigger to GND.  Gives nice output.  Rarely seen this
> simple circuit published.  

 Probably because of 
a) The nasty loads often seen on 555 lash-ups :-)
b) The Bipolar 555's did not go rail-rail on the output
   so Freq tolerance is not as good.

 You are right tho, a single RC two terminal config works,
( same as HC14/40106 circuit) and well with a CMOS version 
- which are just ~25c.

 Because C555's are 'everywhere', they are a better education/prototype
choice than TinyLogic, but I have seen designers swear they will never
ship anything with a 555 in it :-)

> Only drawback I know is that output doesn't
> go rail to rail for bipolar version (but does for CMOS).

-jg

Article: 34171
Subject: Re: fpga with the smallest i/o setup and hold requirement
From: "Dave Feustel" <dfeustel1@home.com>
Date: Wed, 15 Aug 2001 23:57:14 GMT
Links: << >>  << T >>  << A >>
DDR interfaces to Spartan/Virtex chips would seem to be sufficiently
common that a reference design would be worth while.
Is there such a reference design in the works?

Thanks.

"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3B7AF3FA.4A934374@xilinx.com...
> Adrianus,
>
> Virtex II is (less than) 300 ps for the DDR setup and hold in the clock
> forwarded case using the DCM.  The DDR clock forwarded interface requires
> a combination of system features to be used, and we just finished
> characterizing the combinations.
>
> For the non-clock forwarded DDR case, the larger numbers apply.
>
> We have released a DDR spec available to the FAE's to cover these
> interfaces.
>
> Single ended HSTL is another matter.  250 MHz is 500 Mb/s, and HSTL isn't
> the best interface to use at these frequencies.  Signal integrity is
> going to be a PhD thesis, and coupling, noise, and jitter will be a tough
> system design road to travel down.
>
> I suggest you run some simple IBIS simulations to look at duty cycle, and
> rise and fall times of the HSTL standards at this frequency.
>
> Austin
> Xilinx FPGA Lab
>
> Adrianus wrote:
>
> > Hi,
> >
> > I'm looking for a device that has very small setup and hold
> > requirement. I'm trying to use this device to capture a 250 MHz DDR
> > bus with single ended HSTL level. Ideally, I would like the device to
> > require not more than 300 ps of setup and hold window. My gross data
> > window is 2ns, but after the driver clk to data skew, edge rate
> > effect, board effect, etc... I don't have much margin left.
> >
> > It seems to me that Xilinx Virtex II is pretty decent, it is spec'ed
> > at 690 ps of setup and 0 hold. Does anyone know any other device
> > that's better??
> >
> > Any help would be greatly appreciated!
> >
> > THanks,
> > Adrianus
>



Article: 34172
Subject: Re: Reconfigurable Computational Accelerator
From: "Dave Feustel" <dfeustel1@home.com>
Date: Thu, 16 Aug 2001 00:11:25 GMT
Links: << >>  << T >>  << A >>
This looks interesting. How do you deal with cpu memory mapping?

"Luke Roth" <roth@harp.cse.psu.edu> wrote in message
news:Pine.SOL.4.33.0108151347090.7311-100000@harp.cse.psu.edu...
> Alternatively, as part of my research (I'm a grad student at Penn
> State) we're building an FPGA accelerator card which resides on the SDRAM
> memory bus.  Much faster than PCI (up to 133MHz x 64 bits vs 33MHz x 32
> bits) and _much_ lower latency.  Our current board has a Virtex XCV300 and
> 64MB of SDRAM, sufficient for quite a few interesting applications.
> There are some limitations with this approach - for example, there
> are no nice interrupt facilities as available on the PCI bus - but other
> than that it seems like a great solution.  We're testing our first board
> now, it will interesting to see what kind of performance we can acheive
> with this method.  If you're interested in some more (admittedly a bit
> outdated) information, check out www.cedcc.psu.edu/smartdimm/
> Luke Roth
>
> On Wed, 15 Aug 2001, Dave Feustel wrote:
>
> > I've been thinking about the i/o interface obstacle that exists between
> > cpu and pci-bus mediated fpga accelerators for a couple of days now.
> > I have come to the conclusion that the way to have *really* fast
> > fpga accelerators is to put a hardwired cpu on the fpga chip along
> > with the accelerator logic and make the entire application run
> > directly from the fpga. You now can get fpgas with ARM, Powerpc
> > and or other custom cpus preprogrammed into them and still have
> > lots of room for your accelerator logic. IP cores for almost every
> > commonly used peripheral are available to be incorporated onto
> > the fpga chip - leave off the interfaces you don't need.
> > Put the whole thing on a PCI card and plug it into your pc to
> > make development easier(download through the pci bus).
> >
> > "Mike Butts" <mbutts@realizer.com> wrote in message
news:3B758FB0.B98CA76A@realizer.com...
> > > Dave Feustel wrote:
> > > > The real short version is
> > > > that the PCI bus interface is so slow relative to the
> > > > speeds of the cpu and accelerator that it usually
> > > > isn't worth adding an accelerator if the interface
> > > > is via the PCI bus.
> > >
> > > This is often, but not necessarily true.  Accelerator architecture
> > > totally depends on your application.  This is exactly what Philip
> > > meant by "how long should a piece of string be".  Not ridicule,
> > > just maybe a little drier wit than we're used to...
> > >
> > > If your application depends on lots of back-and-forth
> > > between the host and the card in its core kernel, PCI is usually
> > > a barrier.  Many early research projects in this field found this
> > > out the hard way.  It's not the bandwidth that matters in such
> > > cases, it's the latency, the round-trip time for a single operation.
> > >
> > > PCI, especially as implemented in modern PCs and workstations,
> > > can be very bad at that.  Mark Shand gave an excellent and
> > > most useful paper about this at FCCM '97, that anyone using PCI
> > > must study:
> > > Laurent Moll and Mark Shand. Systems performance measurement on
> > > PCI Pamette. In FPGAs for Custom Computing Machines
> > >      (FCCM'97). IEEE, April 1997.
> > > http://www.research.compaq.com/SRC/staff/shand/bib.html
> > >
> > > If, on the other hand, your app is a self-contained kernel that
> > > grinds away mostly on its own, PCI can be fine.  Often signal
> > > processing apps are like this, with the signal I/O direct to
> > > the card.
> > >
> > > I believe a very big win for reconfigurable computing is for
> > > apps that demand lots of parallel memory bandwidth, since the
> > > processor-memory bottleneck is so fundamental to conventional
> > > computing.  I'm working with a project at Oregon Graduate Institute
> > > lately to develop a neural network accelerator.  In our case, it's all
> > > about memory bandwidth.  I/O to/from the host is orders of
> > > magnitude less.  We're planning a PCI card with as many SDRAM DIMMs
> > > as we can hook up to some FPGAs for them to grind away on matrix-
> > > vector multiplies in parallel at 100 MHz.  PCI will just control
> > > and program the card, and feed inputs and collect results at a
> > > lazy and latency-insensitive pace.
> > >
> > > So tell us more about your application, and maybe we can give you
> > > better advice.
> > >
> > >    --Mike
> >
> >
> >
>



Article: 34173
Subject: Re: Building a clock out of a PLD
From: Ken Smith <kensmith@rahul.net>
Date: 16 Aug 2001 00:33:35 GMT
Links: << >>  << T >>  << A >>
In article <irqlnt4nqj2v1uunb4eh5r7qed4cc29041@4ax.com>,
Eric Inazaki  <einazaki@mac.com> wrote:
>Do you recall what kind of PLD you used?  Also, what frequency were
>you running?

In one case is was a T.I.  TICPAL22V10Z running at about 5KHz.

In another case it was an I.C.T. 7024 running at about 100KHz

I've also made XTAL oscillators using PALs a the inverter.

-- 
--
kensmith@rahul.net   forging knowledge


Article: 34174
Subject: Re: Building a clock out of a PLD
From: Ken Smith <kensmith@rahul.net>
Date: 16 Aug 2001 00:41:22 GMT
Links: << >>  << T >>  << A >>
In article <e00c15a3.0108151347.3b07add1@posting.google.com>,
Martin Rice <jmrice@ntlworld.com> wrote:
[.. RC oscillator on Cool runner...]
>Unfortunately, the signal generated was useless as a clock for further
>circuits inside the CPLD!  Not sure why... the square waves had nice
>clean edges.  I guess the chip didn't like the slow edges at A.

There are some funnies in the Cool-Runner that I doubt have ever been
documented.  If you use it for a XTAL oscillator, it is best to use up
another whole cell just to buffer the signal going to the clock pin.  I
think the transistors in the input circuits respond up to the GHz range to
funnies on the edge.

>I ended up using 555.  R from output to threshold/trigger; 
>C from threshold/trigger to GND.  Gives nice output.  Rarely seen this
>simple circuit published.  Only drawback I know is that output doesn't
>go rail to rail for bipolar version (but does for CMOS).

The output of the LM555 can have cross over distortion on it.  If
you use Pin 7 (I think) the open collector transistor driving a resistor
makes quite a nice logic signal.
 
-- 
--
kensmith@rahul.net   forging knowledge




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