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 67800

Article: 67800
Subject: Re: PCI Development Board
From: Kevin Brace <k0evinbr1ace@m2ail.c3om>
Date: Fri, 19 Mar 2004 09:27:36 -0600
Links: << >>  << T >>  << A >>
Hi Spike,

I own the Insight Electronics PCI card mentioned in the article, but it
has been discontinued some time ago and replaced with a newer version.

http://www.insight.na.memec.com/Memec/iplanet/link1/SpartanII200PCI.pdf


You might also want to consider Avnet Spartan-3 evaluation card if you
don't mind the higher price and a minor violation of the PCI
specification (i.e., voltage converters between the Spartan-3 and the
PCI card edge.).

http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D7816%2526CCD%253DUSA%2526SID%253D4746%2526DID%253DDF2%2526SRT%253D1%2526LID%253D0%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html


        Spike, have you considered what to do with the PCI interface
once you purchase the card?
I am planning to release a PCI IP core I developed around end of May.
It will be available for $100 as long as the user agrees to use it for
non-commercial, non-profit, non-academic research, and personal
purposes.
The licensee will need a PayPal account to send the payment, and a Yahoo
account to download the PCI IP core.
I was originally planning to make the PCI IP core was going to be
available only to people residing in the United States who have a valid
PayPal account, but I changed my mind, and it will now be available to
people who have a valid PayPal account living overseas as well.


Here is what my PCI IP core will look like:

* PCI Local Bus Revision 2.2 compliant.
* Burst initiator/target access support.
* 6 Base Address Register (BAR) and Expansion ROM BAR support.
* Meets 33MHz PCI timings with Spartan-II-5
* General purpose PCI testbench comes with a PCI arbiter, PCI host
bridge emulator, and PCI target device to allow the user to quickly
debug their design.
* The PCI IP core supplied in NGO netlist format (Xilinx's proprietary
netlist format.).
* Nominally supports Xilinx Virtex, Spartan-II, or newer FPGAs.
* Constraint file supplied for Spartan-II PQ208 and FG456 package,
Virtex-E XCV300E BG432 package, Insight Electronics Spartan-II 150 PCI
card, and Spartan-II 200 PCI card.
* Comes with three reference designs (Two similar target only designs
and one target/initiator design.).
* Fully supports Verilog (Reference designs and the PCI testbench are
written in Verilog.).
* Limited VHDL support (No reference designs and PCI testbench. Verilog
version of the reference designs and PCI testbench will eventually be
ported to VHDL.).
* Supports ISE WebPACK 3.2 through ISE WebPACK 6.2 (The use of ISE
WebPACK 5.1 or later is strongly recommended.).



Kevin Brace

P.S. Remove the weird numbers from the E-mail address when contacting
me.



Spike wrote:
> 
> Hi again!
> 
> I just looked at this: http://www.xilinx.com/xcell/xl38/xcell38_13.pdf, but
> I'm not sure where I can buy it and whether or not it fulfills me needs...
> Has any one tried it?
> 
> //SPike

Article: 67801
Subject: Re: Altera Quartus Compilation Report
From: petersommerfeld@hotmail.com (Peter Sommerfeld)
Date: 19 Mar 2004 07:39:07 -0800
Links: << >>  << T >>  << A >>
The Stratix logic cell contains one LUT and one register. The register
can be fed either from the LUT output or directly. Probably the best
diagram of the logic cell internals is on pg 2-7 of
http://www.altera.com/literature/hb/stx/ch_2_vol_1.pdf.

-- Pete

maxlim79@hotmail.com (Maxlim) wrote in message news:<a6140565.0403190246.131b49f1@posting.google.com>...
> In Altera Quartus compilation report of Stratix device, it shows the
> usage of logic cells, registers, memory bits, DSP elements, and etc.
> From Stratix device documentation, I read about logic cells, memory
> bits. ... in Stratix architecture except the registers. Just saw some
> input/output register in the DSP blocks.
> 
> Can somebody explain to me where is the registers showed by the
> compilation report in Stratix architecture?

Article: 67802
Subject: Re: Why It Is not Recommended to Infer latches in VLSI Design...
From: Mark Schellhorn <mark@seawaynetworks.com>
Date: Fri, 19 Mar 2004 10:58:52 -0500
Links: << >>  << T >>  << A >>
A latch is an asynchronous circuit element. Many ASIC designs are done using 
strictly synchronous elements in order to allow the use of full internal scan 
testing. Scan testing relies on the circuit under test being a purely 
synchronous structure, so any latches in the design won't be part of a 
"standard" scan chain, resulting in test coverage holes.

This design-for-test practise obviously does not apply to FPGA's, so if a latch 
is what you need, infer away. Just be careful that you do not infer a latch 
where you intend to infer a flip flop.

     Mark


arvind wrote:
> Hi all,
>        So many Books and articles on Web told me to Avoid Infer
> latches in design, But Thay did't give the Proper reason behind this
> and i did't convince. So can anybody give me the Short and Sweet
> answer about my Question "why it is recommended to avoid latches in
> Digital Designs?"
> 
> Thanks for any Reply.
> 
> Best Regards
> Arvind Singh Tomar.

Article: 67803
Subject: Re: Xilinx ISE 6.2 and Virtex-II
From: Ray Andraka <ray@andraka.com>
Date: Fri, 19 Mar 2004 11:14:57 -0500
Links: << >>  << T >>  << A >>
Sounds like you are trying to do 18x18 unsigned multiplication.  The
multipliers are 18x18 SIGNED only.  For unsigned, you are constrained
to 17x17 and you have to tie the msbs to '0'.

David Roberts wrote:

> Hi,
>
> Can anyone suggest how to prevent ISE from synthesising one 18x18
> multiplication to 3 multiplier blocks?
>
> Thanks,
>
> Dave.

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

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



Article: 67804
Subject: reading from a XSA-50
From: nospamplease@bitnet.info (Sebastian)
Date: 19 Mar 2004 08:36:09 -0800
Links: << >>  << T >>  << A >>
Hi. I've got a XSA-50 and the according ps2 cable. I want to read back
signals from the board into a C application, in order to draw
waveforms, etc. I heard there are a few libraries arround, but
couldn't "stumble" on one so far. Any ideas where I should be
looking?:)

Article: 67805
Subject: Re: LVTTL Spartan-3 pin input current...
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 19 Mar 2004 09:10:38 -0800
Links: << >>  << T >>  << A >>
When they are not actively driving, and when the weak pull-up or -down
option is disabled, Xilinx I/O pins draw practically no current. The spec
says max 10 µA, but in reality it is far less. DC current is not your
problem, capacitive load is something you should be concerned about.

For those of us that grew up with TTL, it is important to remember:
CMOS has no input current, and also no output offset. An unloaded output
drives all the way to Vcc or to ground. Isn't that nice!
Peter Alfke 
===============================
> From: sgarcia_castillo@hotmail.com (Sergio)
> Organization: http://groups.google.com
> Newsgroups: comp.arch.fpga
> Date: 19 Mar 2004 06:56:54 -0800
> Subject: Re: LVTTL Spartan-3 pin input current...
> 
> Thanks Bob, I'll be working with some parts provided by Memec, I'll
> let you know how much current each pin sinks as soon as I finish the
> board. I was a bit concerned since I am designing a multichannel
> system, I need to implement data and address buses with 32
> Spartan-3(400). For the data bus there is no problem since while one
> FPGA provides the data at the bus, the others are in high impedance;
> however, the adress bus has to be listened by every FPGA (5 pins), if
> the current that each pin sinks is in micro-amps levels even a normal
> LVTTL source can provide enough current for all FPGAs (I was thinking
> to use a CPLD to provide the address bus); nevertheless, if the
> current is more than that I have other options that involve more
> components in my board. Another option is to provide a CS signal for
> each FPGA, then just one listener per source pin is required with 32
> tracks more. What do you think?, thanks again for your help
> 
> Sergio


Article: 67806
Subject: Re: Why It Is not Recommended to Infer latches in VLSI Design...
From: wv9557@yahoo.com (Will)
Date: 19 Mar 2004 09:50:12 -0800
Links: << >>  << T >>  << A >>
process(input)
begin
if (input='1')then
output<='1';
end if;
end process;

Once output goes hi, it can't never go low again.

arvindstomar@india.com (arvind) wrote in message news:<56147fd4.0403190344.796d99e9@posting.google.com>...
> Hi all,
>        So many Books and articles on Web told me to Avoid Infer
> latches in design, But Thay did't give the Proper reason behind this
> and i did't convince. So can anybody give me the Short and Sweet
> answer about my Question "why it is recommended to avoid latches in
> Digital Designs?"
> 
> Thanks for any Reply.
> 
> Best Regards
> Arvind Singh Tomar.

Article: 67807
Subject: Re: duration of reset
From: Brian Philofsky <brian.philofsky@no_xilinx_spam.com>
Date: Fri, 19 Mar 2004 11:08:21 -0700
Links: << >>  << T >>  << A >>


valentin tihomirov wrote:
> 
> Thank you for the idea. But I'm missing something: UNISIM is post-synthesis
> library. However, functional and post-synthesis simulations don't require
> long reset. This problem is observed only in timing simulation.

For timing simulation with Xilinx FPGAs, a global set/reset (GSR) is 
automatically asserted at the begining of simulation.  The reason for 
this is to mimic what happens after configuration of the FPGA.  One of 
the final stages of conifguration is the assertion of the GSR net (a 
dedicated wire connected to the set or reset of every FF in the FPGA) to 
bring the design into a known state after the completion of 
configuration.  For timing simulation, you can think of the start of 
simulation as being the beginning of the assertion of the GSR net and 
similar as in the real FPGA, the purpose to include this in simulation 
is to ensure the simulation starts in that same known state as the FPGA 
would.  The default value for this in simulation is 100 ns but that can 
be changed by either adding the appropriate switch to netgen or changing 
the appropriate property for simulation netlist generation in Project 
Navigator however I generally suggest to just leave it at 100 ns.  Why 
100 ns?  100 ns is not the actual value of the GSR pulse but was an 
arbitrary round number choosen so that it is easy to know when GSR ends 
and does not take too much simulation time away but does give a chance 
for all clocks and input stimulus to become stable in the simulation. 
The actual amount of time is dependent on many things including which 
device you target, whether you are using the STARTUP block or not, as 
well as process and environmental factors so choosing a round 100 ns 
number makes it easier to build your testbench knowing when that GSR 
pulse ends.

So what does all of this mean to you?  You must account for this GSR 
pulse in your timing simulation. You can change the duration of this but 
it is not suggested.  You should still initialize all input stimilus and 
drive your clocks at time zero however I would not drive stimulus you 
expect to react for simulation until after the 100 ns pulse has 
completed.  In fact, I generally recommend for functional simulation, to 
also hold off processing data util after 100 ns has passed so that the 
same testbench can be used for both functional and timing simultaion.

As for the simple code snip you posted previously, I am not sure if that 
would do anything in a timing simulation or the chip itself for that 
matter.  I would need to see the rest to be sure but based on what I 
saw, most likely what would happen if the circuit was not optimized to a 
'logic 1' on that output would be that the GSR would drive that inferred 
FF to a 'logic 1' so that at 100 ns when you should start driving your 
stimulus, that register will already be a 'logic 1'.  I think your test 
is a little too simple to try to figure out FPGA functionality or 
timing.  You might want to try a little more substantial test where the 
FF is at least clocking in data to better understand how this would be 
inplemented.  My guess at what your issue ther is that this example is 
so simple it is being optimized to the point that you are not seeing 
what you might expect.


--  Brian




Article: 67808
Subject: Re: Why It Is not Recommended to Infer latches in VLSI Design...
From: mike_treseler@comcast.net (Mike Treseler)
Date: 19 Mar 2004 10:10:01 -0800
Links: << >>  << T >>  << A >>
arvind wrote:

> So can anybody give me the Short and Sweet
> answer about my Question "why it is recommended to avoid latches in
> Digital Designs?"

Because latches are incompatible with synchronous
design and automated static timing analysis.

     -- Mike Treseler

Article: 67809
Subject: Re: PCI Development Board
From: Eric Crabill <eric.crabill@xilinx.com>
Date: Fri, 19 Mar 2004 10:19:40 -0800
Links: << >>  << T >>  << A >>

Hi,

You, or anybody else who's interested in a Virtex based PCI
prototyping board, can go to:

http://www.engr.sjsu.edu/crabill/projects/nxm/readme.htm
http://www.engr.sjsu.edu/crabill/projects/nxm/

Download the gerber photoplots, bill of materials, and
schematics.  You can build some for yourself and sell the
rest if you want (I don't care...)

Eric

Spike wrote:
> 
> ok, I would like to make my own PCI board (a stand-alone PCI card which I
> can insert in an computer with a free PCI slot). Nothing fancy just a board
> that could send out I/O data or what ever.
> 
> For this task I've heard that FPGA would be a good choice.
> 
> I don't know how to explain it better but if I've missed something, let me
> know.
> 
> Thanks!
> 
> //SPike
> 
> "rickman" <spamgoeshere4@yahoo.com> skrev i meddelandet
> news:405A4A18.5555C689@yahoo.com...
> > Spike wrote:
> > >
> > > I can't say I know enough about FPGA processors to choose a good one,
> that's
> > > mainly why asked this question. I was hoping that you could give me some
> > > advices...
> >
> > That will require that you explain in detail what you want to do with
> > it.  And be prepared for a lot of advice on what you want to do as well
> > as how to do it... ;)
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@XYarius.com
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design      URL http://www.arius.com
> > 4 King Ave                               301-682-7772 Voice
> > Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 67810
Subject: Re: Speed of Linux vs Solaris
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 19 Mar 2004 10:29:40 -0800
Links: << >>  << T >>  << A >>
David Rogoff wrote:
> ...
> I assume the floating licenses will share across - correct?

At least with Synplify, yes the floating license works with the Linux 
version of Synplify. In fact, it is required; at least the last time I 
checked, a node locked license was not available for Linux :-(



Article: 67811
Subject: Leonardo Spectrum error message
From: "Kurt Müller" <mueller@NOSPAMpo.dia.dk>
Date: Fri, 19 Mar 2004 20:11:25 +0100
Links: << >>  << T >>  << A >>
Hi

"Current design is not a view"

I get this error message when trying to running a synthesis script for an
Spartan XL fpga.
I have run my script several times without errors, but now i get this
message each time i try to run the script, and the script stops running.
I'm running my script from within the UI using the source command.
I still can run the synthesis using the UI, so the error is not related to
the hld code.

Any sugestion what i have messed up in my setup, and what the cure is to
bring my design back on track.

Regards

Kurt Müller
Denmark





Article: 67812
Subject: Re: Added example VC++ program to download XIlinx FPGAs
From: do_not_reply_to_this_addr@yahoo.com (Sumit Gupta)
Date: 19 Mar 2004 11:33:03 -0800
Links: << >>  << T >>  << A >>
"Kelvin @ SG" <kelvin8157@hotmail.com> wrote in message news:<405a9fdf$1@news.starhub.net.sg>...
> Gupta,
> 
> Are you willing to release the source code for sasm.exe?

Its already there. Click on downloads in the sidebar.

Sumit

> 
> Best Regards,
> Kelvin
> 
> 
> Sumit Gupta <do_not_reply_to_this_addr@yahoo.com> wrote in message
> news:4ru6c.26051$nH2.4810@newssvr29.news.prodigy.com...
> > I wrote a sample VC++ program to download Xilinx FPGAs via slave serial
>  mode
> > using JTAG cable (parallel cable III). I have posted it to my website. Its
> > compiled as a windows console application. I used inpout32.dll library to
> > talk to parallel port of the PC. The program works on my win2K laptop.
> >
> > Sumit
> > -----
> > http://www.c-nit.net
> >
> >

Article: 67813
Subject: Re: LVTTL Spartan-3 pin input current...
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 19 Mar 2004 14:44:49 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> When they are not actively driving, and when the weak pull-up or -down
> option is disabled, Xilinx I/O pins draw practically no current. The spec
> says max 10 µA, but in reality it is far less. DC current is not your
> problem, capacitive load is something you should be concerned about.
> 
> For those of us that grew up with TTL, it is important to remember:
> CMOS has no input current, and also no output offset. An unloaded output
> drives all the way to Vcc or to ground. Isn't that nice!

Peter,

I have always wondered about this, but never come to any conclusions. 
TTL circuits had a limit to the pullup voltage of about 3 volts when
powered by 5 volts.  That was above the 2.4 volt requirement, so it was
fine.  

When a CMOS technology is spec'd to the same TTL standards on input and
output (0.8/0.4 low, 2.0/2.4 high) do they *always* pull up to Vdd if
there is no appreciable load?  I never wanted to make any assumptions in
case there are CMOS outputs that are *not* designed to pull up to Vdd.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 67814
Subject: Altera DSP Builder
From: rrr@ieee.org (Rajeev)
Date: 19 Mar 2004 12:19:50 -0800
Links: << >>  << T >>  << A >>
Hello All and particularly Justin Cowling (see excerpt below)

Don't see too much here re: DSP Builder or SystemGenerator...

I am trying out for the first time the DSP Builder 2.1.3 for a portion
of my design.  Pleased to report that installation was trouble-free,
haven't yet generated any VHDL.  I am comfortable with VHDL,
proficient
at Matlab and can do simple stuff with Simulink.

I care about (1) getting the job done faster, which I'm looking
forward
to being better able to see what I'm doing as I go along (2) hopefully
much easier to validate minor/modest functional changes.

Can an enlightened person help me with the following questions :

1. In my design I extensively use true dual port RAM with different
sizes
on Port A and Port B.  The Altera DSP Builder provides what appears to
be simple dual port RAM with same size on Port A and Port B.  Is there
either a workaround or a subsystem model available somewhere that
builds a true dual port RAM out of existing components ?  For me, only
one port needs write access, but both ports need read.

> If you compare DSP Builder to HDL's and
> you are more comfortable with HDL's, the main reasons for working with
> DSP Builder will be for the verification flow.

2. I was intrigued by the SubSystemBuilder block which allows you to
import existing VHDL, but it appears that I can only import VHDL
entities, not the components.  Aside from being a pain to draw
graphically something that's already working in VHDL, I am also
confused about how this fits in with verification.  It would appear
a big weakness to have comprehensively tested something different
from what you're going to deploy.  What's the intent here ?

3. It would be really neat to be able to run my existing VHDL as
part of my Simulink simulation.  (In fact when I first heard about
DSP Builder I had the wild hope that it could convert *any* Simulink
model into VHDL -- but I can appreciate the difficulty in that.)
The converse however, VHDL->Simulink may be easier.  I'm sure Altera
has people working on it, question is how far off is this ?

Thanks for any enlightenment,
-rajeev-

-----------------------
On Jan 31,2003 Justin Cowling wrote:

http://groups.google.com/groups?q=altera+dsp+builder+group:comp.arch.fpga&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.arch.fpga&selm=316e0ba7.0301310711.4b766065%40posting.google.com&rnum=1

> Your question about the quality of these tools is a good one. The
> evolution of Altera's DSP Builder has been extremely rapid over the
> last two years.  With the latest release of DSP Builder 2.1, major
> strides have been made in overall capability and quality.  These tools

<...>

> DSP Builder Weaknesses
> - DSP Builder does have a graphical Finite State Machine, however,
> many consider language based control capture significantly more
> productive (assuming you know how to write HDL).
> - DSP Builder only supports a sub-set of all Altera and 3rd party IP
> because it requires Mathworks C models for every block.
> - Currently, DSP Builder only supports VHDL.

> If you compare the capabilities of DSP Builder and Simulink against
> comparable tools like SPW, DSP Builder does essentially the same thing
> for a fraction of the cost.  If you compare DSP Builder to HDL's and
> you are more comfortable with HDL's, the main reasons for working with
> DSP Builder will be for the verification flow.

> If you want a graphical tool for implementing DSP hardware, DSP
> Builder and Simulink have leading edge capabilities and a low price.

> Justin Cowling
> Director IP Marketing
> Altera Corp

Article: 67815
Subject: Re: Why It Is not Recommended to Infer latches in VLSI Design...
From: Larry Doolittle <ldoolitt@recycle.lbl.gov>
Date: Fri, 19 Mar 2004 20:30:16 +0000 (UTC)
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> arvind wrote:
>> So can anybody give me the Short and Sweet
>> answer about my Question "why it is recommended to avoid latches in
>> Digital Designs?"
> 
> Because latches are incompatible with synchronous
> design and automated static timing analysis.

Right.  Infer flip-flops instead.  In Verilog:

reg foo;
always @(posedge clk) foo <= some_expression;

or the more verbose and not necessarily more useful:

reg foo;
always @(posedge clk or posedge rst) if (rst) begin
	foo <= 0;
end else begin
	foo <= some_expression;
end

I'll leave the VHDL versions to someone else.
My fingers get tired too quickly.  ;-)

If someone wants to argue that the above is not
really inference, I would counter that since it
is not an instantiation of a primitive, it must
be inference.  What other (named) categories of
resultant hardware are there in a HDL?

    - Larry

Article: 67816
Subject: Re: Why It Is not Recommended to Infer latches in VLSI Design...
From: ccon <>
Date: Fri, 19 Mar 2004 12:33:24 -0800
Links: << >>  << T >>  << A >>
Well,...how can we write/read data  to a fast SRAM with address access time < 10ns?

Article: 67817
Subject: Re: LVTTL Spartan-3 pin input current...
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 19 Mar 2004 13:31:50 -0800
Links: << >>  << T >>  << A >>
All conventional CMOS output ( not "open collector" GTL and the almost
linear LVDS) sink and source "rail-to-rail". No inherent offset voltage at
zero current. Close to ground and Vcc the outputs are resistive to the first
approximation.
The 2.0/2.4 V and 0.4/0.8 V specs are historical baggage from the TTL days,
same as inches and feet are relics from old English kings' body dimensions.

Peter Alfke

> From: rickman <spamgoeshere4@yahoo.com>
> Reply-To: spamgoeshere4@yahoo.com
> Newsgroups: comp.arch.fpga
> Date: Fri, 19 Mar 2004 14:44:49 -0500
> Subject: Re: LVTTL Spartan-3 pin input current...
> 
> Peter Alfke wrote:
>> 
>> When they are not actively driving, and when the weak pull-up or -down
>> option is disabled, Xilinx I/O pins draw practically no current. The spec
>> says max 10 µA, but in reality it is far less. DC current is not your
>> problem, capacitive load is something you should be concerned about.
>> 
>> For those of us that grew up with TTL, it is important to remember:
>> CMOS has no input current, and also no output offset. An unloaded output
>> drives all the way to Vcc or to ground. Isn't that nice!
> 
> Peter,
> 
> I have always wondered about this, but never come to any conclusions.
> TTL circuits had a limit to the pullup voltage of about 3 volts when
> powered by 5 volts.  That was above the 2.4 volt requirement, so it was
> fine.  
> 
> When a CMOS technology is spec'd to the same TTL standards on input and
> output (0.8/0.4 low, 2.0/2.4 high) do they *always* pull up to Vdd if
> there is no appreciable load?  I never wanted to make any assumptions in
> case there are CMOS outputs that are *not* designed to pull up to Vdd.
> 
> -- 
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 67818
Subject: Re: LVTTL Spartan-3 pin input current...but if you give him a centimeter,
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 19 Mar 2004 13:50:31 -0800
Links: << >>  << T >>  << A >>
But,

In the not-so-very-old-days where nmos transistors were cheaper (in 
area) and faster (in performance)than the pmos transistors, one could 
build an output structure that had only nmos transistors for the pullup 
and pulldown.

Such a structure could not pull any closer than a Vt to the Vcc rail, 
and thus "5V all nmos" output stacks looked just like a TTL output 
stack, and had similar voltage levels.

To tolerate very large overshoot, sometimes two nmos were used in 
series, and then it even looked more like TTL, with a strong pull down, 
and relatively weaker pull up.

Austin

Peter Alfke wrote:
> All conventional CMOS output ( not "open collector" GTL and the almost
> linear LVDS) sink and source "rail-to-rail". No inherent offset voltage at
> zero current. Close to ground and Vcc the outputs are resistive to the first
> approximation.
> The 2.0/2.4 V and 0.4/0.8 V specs are historical baggage from the TTL days,
> same as inches and feet are relics from old English kings' body dimensions.
> 
> Peter Alfke
> 
> 
>>From: rickman <spamgoeshere4@yahoo.com>
>>Reply-To: spamgoeshere4@yahoo.com
>>Newsgroups: comp.arch.fpga
>>Date: Fri, 19 Mar 2004 14:44:49 -0500
>>Subject: Re: LVTTL Spartan-3 pin input current...
>>
>>Peter Alfke wrote:
>>
>>>When they are not actively driving, and when the weak pull-up or -down
>>>option is disabled, Xilinx I/O pins draw practically no current. The spec
>>>says max 10 µA, but in reality it is far less. DC current is not your
>>>problem, capacitive load is something you should be concerned about.
>>>
>>>For those of us that grew up with TTL, it is important to remember:
>>>CMOS has no input current, and also no output offset. An unloaded output
>>>drives all the way to Vcc or to ground. Isn't that nice!
>>
>>Peter,
>>
>>I have always wondered about this, but never come to any conclusions.
>>TTL circuits had a limit to the pullup voltage of about 3 volts when
>>powered by 5 volts.  That was above the 2.4 volt requirement, so it was
>>fine.  
>>
>>When a CMOS technology is spec'd to the same TTL standards on input and
>>output (0.8/0.4 low, 2.0/2.4 high) do they *always* pull up to Vdd if
>>there is no appreciable load?  I never wanted to make any assumptions in
>>case there are CMOS outputs that are *not* designed to pull up to Vdd.
>>
>>-- 
>>
>>Rick "rickman" Collins
>>
>>rick.collins@XYarius.com
>>Ignore the reply address. To email me use the above address with the XY
>>removed.
>>
>>Arius - A Signal Processing Solutions Company
>>Specializing in DSP and FPGA design      URL http://www.arius.com
>>4 King Ave                               301-682-7772 Voice
>>Frederick, MD 21701-3110                 301-682-7666 FAX
> 
> 

Article: 67819
Subject: Re: Why It Is not Recommended to Infer latches in VLSI Design...
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Fri, 19 Mar 2004 16:57:22 -0500
Links: << >>  << T >>  << A >>
On Fri, 19 Mar 2004 10:10:01 -0800, Mike Treseler wrote:

> arvind wrote:
> 
>> So can anybody give me the Short and Sweet
>> answer about my Question "why it is recommended to avoid latches in
>> Digital Designs?"
> 
> Because latches are incompatible with synchronous
> design and automated static timing analysis.
> 
>      -- Mike Treseler

Nonsense. I'll grant that it's harder to do a static timing analysis on a
latch based design but it's perfectly doable. In an ASIC a latch design
has a lot of advantages, 

latches have 1/2 transistors of flipflops (not applicable to FPGAs)

non-overlaping clock latch designs are less sensitive to clock skew

the clock to out of the latch is not in the critical path

There is a delay averaging effect, i.e. if one stage of a pipe is fast and
the next is slow, the slow stage gets to use the spare picoseconds left
over by the fast stage.

All of these things contribute to a faster clock rate.

In an FPGA there are fewer advantages to doing a latch based design then
in an ASIC. Flipflops and latches have the same cost in a FPGA, the clock
trees are well defined so the clock skew advantage isn't there, and
finally other things are likely to limit your clock speed so the improved
performance of latch based data path is unlikely to help you. The
disadvantage of a latch based design is that it is harder to do so unless
you really need the maximum possible performance you are generally better
off using a register based design, especially in an FPGA.


Article: 67820
Subject: What's the flow V2P SysAce handles the software inside the ACE file
From: John Black <black@eed.com>
Date: Fri, 19 Mar 2004 15:00:13 -0700
Links: << >>  << T >>  << A >>
Hi,
   I am amazed at how SysAce handles the hardware and software: the ACE
file should have 2 parts, FPGA programming bit file and the ELF file
which will be loaded into external memory. I know the trick is JTAG, but
I want to get a closer look what the underneath flow is. SysAce load the
bit file to program the FPGA, and then it ask PowerPC to load the ELF to
the external memory? What exactly happens?
   I check out the data sheet of SysAce CF, but it does not mention this
flow. I wonder if somewhere else has this?

Thanks.


Article: 67821
Subject: Re: duration of reset
From: Sudhir.Singh@email.com (Sudhir Singh)
Date: 19 Mar 2004 14:02:44 -0800
Links: << >>  << T >>  << A >>
Hi Valentin,
If you don't include the ROC component in your VHDL design then your
functional/behavioural simulations won't show the long reset. The ROC
component is inserted automatically (if you haven't included it)
during back-annotation
by ngd2vhdl for post implementation timing simulations.By default this
reset is for 100ns.
Refer to the section on Emulating the Global GSR pulse in VHDL in
Functional Simulation in Synthesis and Verification Design Guide.
Sudhir 



"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in message news:<c3ebsc$25po73$1@ID-212430.news.uni-berlin.de>...
> > Also use the following library:
> > library UNISIM;
> > use unisim.vcomponents.all;
> > search for ROC at Xilinx website, you'll find lots of info there.
> Thank you for the idea. But I'm missing something: UNISIM is post-synthesis
> library. However, functional and post-synthesis simulations don't require
> long reset. This problem is observed only in timing simulation.

Article: 67822
Subject: Re: PCI Development Board
From: "Spike" <me.hates:spam@me.net>
Date: Fri, 19 Mar 2004 22:10:11 GMT
Links: << >>  << T >>  << A >>

"Kevin Brace" <k0evinbr1ace@m2ail.c3om> skrev i meddelandet
news:c3f37u$qa4$1@newsreader.mailgate.org...
> Hi Spike,
>
> I own the Insight Electronics PCI card mentioned in the article, but it
> has been discontinued some time ago and replaced with a newer version.
>
> http://www.insight.na.memec.com/Memec/iplanet/link1/SpartanII200PCI.pdf

I looked at the "Included" list and didn't find any IDE or similiar for
development of VHDL programs. Do I have to buy that separate?

>
>
> You might also want to consider Avnet Spartan-3 evaluation card if you
> don't mind the higher price and a minor violation of the PCI
> specification (i.e., voltage converters between the Spartan-3 and the
> PCI card edge.).
>
>
http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D7816%2526CCD%2
53DUSA%2526SID%253D4746%2526DID%253DDF2%2526SRT%253D1%2526LID%253D0%2526PVW%
253D%2526BID%253DDF2%2526CTP%253DEVK,00.html
>
>
>         Spike, have you considered what to do with the PCI interface
> once you purchase the card?

While I'm waiting for the card I will try to read some books on FPGA's, VHDL
and so on. Once I get it I will try to
test a couple of test - examples that I hope are included just to see how
the machine really works.

After a while I will try to build a valid PCI Configuration Space (what
Vendor/Device ID's did you use? are there any reserved for hobby purpose?)
to test if my PCI design works. As soon as the design works I will try to
read the PCI spec(s). more carefully to learn how the mechanical &
electrical parameters should be implemented.

But the real purpose of building a PCI card will be (in the beginning) just
for fun. After a while I might try to build a I/O controller and maybe add
something more advanced.

If you know of any good books on VHDL, FPGA with PCI in mind or similar I
would be glad if you could tell me.

How did you start?

Thanks for your help!

//SPike

> I am planning to release a PCI IP core I developed around end of May.
> It will be available for $100 as long as the user agrees to use it for
> non-commercial, non-profit, non-academic research, and personal
> purposes.
> The licensee will need a PayPal account to send the payment, and a Yahoo
> account to download the PCI IP core.
> I was originally planning to make the PCI IP core was going to be
> available only to people residing in the United States who have a valid
> PayPal account, but I changed my mind, and it will now be available to
> people who have a valid PayPal account living overseas as well.
>
>
> Here is what my PCI IP core will look like:
>
> * PCI Local Bus Revision 2.2 compliant.
> * Burst initiator/target access support.
> * 6 Base Address Register (BAR) and Expansion ROM BAR support.
> * Meets 33MHz PCI timings with Spartan-II-5
> * General purpose PCI testbench comes with a PCI arbiter, PCI host
> bridge emulator, and PCI target device to allow the user to quickly
> debug their design.
> * The PCI IP core supplied in NGO netlist format (Xilinx's proprietary
> netlist format.).
> * Nominally supports Xilinx Virtex, Spartan-II, or newer FPGAs.
> * Constraint file supplied for Spartan-II PQ208 and FG456 package,
> Virtex-E XCV300E BG432 package, Insight Electronics Spartan-II 150 PCI
> card, and Spartan-II 200 PCI card.
> * Comes with three reference designs (Two similar target only designs
> and one target/initiator design.).
> * Fully supports Verilog (Reference designs and the PCI testbench are
> written in Verilog.).
> * Limited VHDL support (No reference designs and PCI testbench. Verilog
> version of the reference designs and PCI testbench will eventually be
> ported to VHDL.).
> * Supports ISE WebPACK 3.2 through ISE WebPACK 6.2 (The use of ISE
> WebPACK 5.1 or later is strongly recommended.).
>
>
>
> Kevin Brace
>
> P.S. Remove the weird numbers from the E-mail address when contacting
> me.
>
>
>
> Spike wrote:
> >
> > Hi again!
> >
> > I just looked at this: http://www.xilinx.com/xcell/xl38/xcell38_13.pdf,
but
> > I'm not sure where I can buy it and whether or not it fulfills me
needs...
> > Has any one tried it?
> >
> > //SPike



Article: 67823
Subject: Re: PCI Development Board
From: "Spike" <me.hates:spam@me.net>
Date: Fri, 19 Mar 2004 22:16:20 GMT
Links: << >>  << T >>  << A >>
"Eric Crabill" <eric.crabill@xilinx.com> skrev i meddelandet
news:405B39BC.3530BAAA@xilinx.com...
>
> Hi,
>
> You, or anybody else who's interested in a Virtex based PCI
> prototyping board, can go to:
>
> http://www.engr.sjsu.edu/crabill/projects/nxm/readme.htm
> http://www.engr.sjsu.edu/crabill/projects/nxm/
>
> Download the gerber photoplots, bill of materials, and
> schematics.  You can build some for yourself and sell the
> rest if you want (I don't care...)

I planning on only using FPGA's for fun so no profit is involved.

>
> Eric

How do you upload the program to the FPGA? As far as I know FPGA's doesn't
haave support for EEPROM so another deivce would have to upload it (I would
be very glad if you could prove me wrong on this one!).

Also, What kind of PCI cards have you developed with the help of this card?
Have you experienced any problems?

Thanks!

//SPike

>
> Spike wrote:
> >
> > ok, I would like to make my own PCI board (a stand-alone PCI card which
I
> > can insert in an computer with a free PCI slot). Nothing fancy just a
board
> > that could send out I/O data or what ever.
> >
> > For this task I've heard that FPGA would be a good choice.
> >
> > I don't know how to explain it better but if I've missed something, let
me
> > know.
> >
> > Thanks!
> >
> > //SPike
> >
> > "rickman" <spamgoeshere4@yahoo.com> skrev i meddelandet
> > news:405A4A18.5555C689@yahoo.com...
> > > Spike wrote:
> > > >
> > > > I can't say I know enough about FPGA processors to choose a good
one,
> > that's
> > > > mainly why asked this question. I was hoping that you could give me
some
> > > > advices...
> > >
> > > That will require that you explain in detail what you want to do with
> > > it.  And be prepared for a lot of advice on what you want to do as
well
> > > as how to do it... ;)
> > >
> > > --
> > >
> > > Rick "rickman" Collins
> > >
> > > rick.collins@XYarius.com
> > > Ignore the reply address. To email me use the above address with the
XY
> > > removed.
> > >
> > > Arius - A Signal Processing Solutions Company
> > > Specializing in DSP and FPGA design      URL http://www.arius.com
> > > 4 King Ave                               301-682-7772 Voice
> > > Frederick, MD 21701-3110                 301-682-7666 FAX



Article: 67824
Subject: Virtex-E IOB programmable delay
From: thangkho <>
Date: Fri, 19 Mar 2004 15:03:59 -0800
Links: << >>  << T >>  << A >>
Hi guys, 
This is what I get from Xilinx datasheet, please confirm me if I am wrong: 

The IOB programmable delay has only two modes delay/nodelay.  When delay 
is implemented, it add just 100ps to data path.



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