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 18875

Article: 18875
Subject: Re: How to use GSR-net in Virtex?
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 19 Nov 1999 12:30:32 -0700
Links: << >>  << T >>  << A >>
eml@riverside-machines.com.NOSPAM wrote in message
<38354f68.18149846@news.dial.pipex.com>...
>On Thu, 18 Nov 1999 09:23:09 -0700, "Andy Peters"
><apeters.Nospam@nospam.noao.edu.nospam> wrote:
>
>>No, neither tedious or unnecessary.  And it is right.  When I write code
>>that's supposed to end up as a flipflop, I always include an async reset
>>that uses the GSR.  That takes care of the power-on reset.  If a flip has
to
>>be (re)set any time other than at power-up, I use a synchronous reset.
>
>Or power-on preset, of course - try doing that without an explicit GSR
>signal.

FPGA Express apparently can do that without instantiating a startup block.
OK, maybe it doesn't work in Virtex but it works in an XLA part.

I just checked an XLA design in FPGA Editor.  Active-low write enable output
pin.  the code is written the usual way; the reset clause sets write_l to
'1'. Looking at the IOB in FPGA Editor, GSR goes into a selector that drives
the flop's async set.

The display for CLBs doesn't explicitly call out the GSR but each flop has a
pair of check boxes, one labelled SET, the other RESET.  One might assume
that the flop is either set or reset upon assertion of GSR, but is that
right?  In any case, a power-on (GSR) preset seems to check the "SET" box.


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.



Article: 18876
Subject: Re: Need advice on interfacing SDRAM modules
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Fri, 19 Nov 1999 12:31:12 -0700
Links: << >>  << T >>  << A >>
Rick Filipkiewicz wrote in message <38354936.AB596951@algor.co.uk>...
>
>
>Andy Peters wrote:
>
>> You should check out the SDRAM data sheets at Micron's web site.  They're
>> large (50 pages) but you really need to understand how the parts work
before
>> attempting a design with them.  They're not necessarily difficult, just
>> idiosyncratic.
>
>On the same site Micron also have some nice Verilog & VHDL simulation
models of
>their SDRAMs that might also help in understanding some of the more obscure
>timing parameters.

got' em; that's why we bought the Micron parts.


--
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"Creation Science" is oxymoronic.



Article: 18877
Subject: Re: Altera Files vho and sdo too big
From: ying@soda.CSUA.Berkeley.EDU (Ying C.)
Date: 19 Nov 1999 19:32:44 GMT
Links: << >>  << T >>  << A >>

In Max+Plus II, with the Compiler Window active, I believe you can go into
the Processing menu and enable "Optimize Timing in SNF". This should reduce
the file sizes. If you migrate to APEX and use the new Quartus SW, the .vo
and .sdo should also be much smaller due to new netlist structure.

Ying

In article <8146re$nl7@netline.jpl.nasa.gov>,
Edwin Grigorian <edwin.grigorian@jpl.nasa.gov> wrote:
>I have had similar sized '.vo' (verilog) and '.sdo' files with a 93% full
>10K200E  (low IO count) and was able to successfully do post Place & Route
>simulations with Modelsim.  Simulations do take quite some time to complete
>if your testbench uses up many cycles.
>
>Edwin Grigorian
>JPL
>
>Rick Filipkiewicz <rick@algor.co.uk> wrote in message
>news:382AA865.C202FD66@algor.co.uk...
>>
>>
>> giuseppe giachella wrote:
>>
>> > After placing and routing my design on an Altera Flex 10KA250, Maxplus2
>> > created two output files .vho and .sdo in order to start
>> > a postlayout simulation. These two files have a dimension of 16 MB
>> > each. It is almost impossible for me to compile such a vhdl and load
>> > an sdf file so big (I have tried using Modelsim and VSS).
>> >
>> > Is there anyone who succeeded in simulating files so big ?
>> >
>> > What should I expect if I migrate my design an a APEX or VIRTEX
>> > (they contain much more gates than a Flex 10KA250) ?
>> >
>>
>> One approach would be to use a perl script to split the postroute netlist
>> into separate pieces and compile them seprately into a library.
>> Alternatively if VHDL makes that difficult and you have the co-simulation
>> version of ModelSim you could output the netlist in the more compact &
>easy
>> to split Verilog form.
>>
>> For my postlayout Virtex XCV300 simulation I get an 8MB Verilog
>netlist+8MB
>> SDF and ModelSim [5.3aPE] handles this with no problems, takes just under
>2
>> minutes to compile - 450MHz P-II + 512MBytes.
>>
>>
>
>


Article: 18878
Subject: Re: Why not Lucent ORCA FGPAs?
From: husby@fnal.gov (Don Husby)
Date: Fri, 19 Nov 1999 19:38:25 GMT
Links: << >>  << T >>  << A >>
An anonymous poster (via Rickman) wrote:
> I have picked the Lucent ORCA FPGAs for the board I am currently
> building due to IO count, part cost and support. I have noticed that
> there are not many people discussing these devices in this newsgroup,
> which I assume is because there are not a lot of people using them. Can
> I ask why Xilinx parts are preferred over the Lucent devices? Other than
> inertia, why did you pick the Xilinx devices?

I started using the Orca parts many years ago after buying Neocad which,
at the time, supported both Xilinx and Orca parts.  I found that the Orca
parts had better performance, more pins, and were cheaper.  I think that
is still true today for Orca 2x series parts vs. Xilinx 4x.

The two big architectural advantages that Orca 2x has are:
 FE-Mux into each flip flop can be used in many cases as an extra logic input.
 Large numbers of tristate lines running vertically and horizontally.
 (There are 2 Tbufs per LUT in the orca part).

However, the OR2x lacks I/O flip flops and also doesn't have a carry
structure as flexible as the X4K chips.

The Orca 3T series has made some improvements over the OR2x.
It now has I/O Flip-Flops.  It's carry structure appears to be more
flexible, but the software doesn't suport it.  (Xilinx has gone the other
way, and made theirs less flexible).  Lucent also added a flip-flop to the
carry chain, making it more efficient for pipelined arithmetic, and for
implementing the 5-bit counters needed to address their 32-word RAMS.

The OR3T has only 1 Tbuf per LUT, but still has horizontal and vertical
tristate lines as well as horizontal and vertical carry chains.  (Virtex
has only vertical carry chains and horizontal tristate lines.  It has 0.5
Tbuf per LUT.)

Lucent has also improved its memory architecture.  It uses 2 LUTS to
implement a 32x1 dual-port memory, while Virtex loses a factor of 2 by
using 2 Luts to make a 16x1 dual-port RAM.

Even with its apparent architectural advantages, the OR3T part doesn't do
as well as Virtex parts for the designs that I've tested.  It appears that
the synthesis software (Leonardo Spectrum) does a much better job for
Virtex parts than for OR3T parts.  


--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 18879
Subject: Re: Why not Lucent ORCA FGPAs?
From: husby@fnal.gov (Don Husby)
Date: Fri, 19 Nov 1999 19:41:46 GMT
Links: << >>  << T >>  << A >>
husby@fnal.gov (Don Husby) wrote:
> An anonymous poster (via Rickman) wrote:

oops.  I misread the Rickman's message.  He was the original
poster, and not posting for someone else.  Sorry.





--
Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
Fermi National Accelerator Lab                          Phone: 630-840-3668
Batavia, IL 60510                                         Fax: 630-840-5406
Article: 18880
Subject: Virtex: Getting flip-flops into the pads
From: "Jamie Sanderson" <jamie@nortelnetworks.com>
Date: Fri, 19 Nov 1999 17:31:19 -0500
Links: << >>  << T >>  << A >>
Greetings;

I'm getting my feet wet with Virtex, after having used the 4000 series for a
few years.

In the past, I've always stayed away from manually instantiating components,
mostly because the code is less readable and portable. This has worked well
with the 4000 parts when it comes to automatic inference of the startup
block and usage of flip-flops in the I/O blocks. Now that I've started
working with Virtex, neither of these works as it once did.

I've read the application notes on the Xilinx site concerning the startup
block and Synplify (the synthesis tool I'm using). Answer #4034 makes it
clear that the startup block won't be instantiated automatically by this
tool under any circumstances (even when force GSR is turned on???).

http://www.xilinx.com/techdocs/4034.htm

Moving on to the bigger problem... Top-level signals which are registered
(either inputs or outputs) aren't being clocked in the pad. I've checked
this using the FPGA editor. The pads are only being used as IBUF or OBUF.
The registering of the signal occurs inside a CLB. What I want, and what
used to happen automatically, is for the register to reside in the pad. Fast
clock to output delays depend on this.

Any helpful suggestions on how to get the registers moved into the pads
would be greatly appreciated. I prefer not to resort to manual instantiation
of any components.

Best regards,
Jamie Sanderson


Article: 18881
Subject: Re: Virtex: Getting flip-flops into the pads
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Fri, 19 Nov 1999 18:10:55 -0500
Links: << >>  << T >>  << A >>
use 

map -pr b

Josh

Jamie Sanderson wrote:
> 
> Greetings;
> 
> I'm getting my feet wet with Virtex, after having used the 4000 series for a
> few years.
> 
> In the past, I've always stayed away from manually instantiating components,
> mostly because the code is less readable and portable. This has worked well
> with the 4000 parts when it comes to automatic inference of the startup
> block and usage of flip-flops in the I/O blocks. Now that I've started
> working with Virtex, neither of these works as it once did.
> 
> I've read the application notes on the Xilinx site concerning the startup
> block and Synplify (the synthesis tool I'm using). Answer #4034 makes it
> clear that the startup block won't be instantiated automatically by this
> tool under any circumstances (even when force GSR is turned on???).
> 
> http://www.xilinx.com/techdocs/4034.htm
> 
> Moving on to the bigger problem... Top-level signals which are registered
> (either inputs or outputs) aren't being clocked in the pad. I've checked
> this using the FPGA editor. The pads are only being used as IBUF or OBUF.
> The registering of the signal occurs inside a CLB. What I want, and what
> used to happen automatically, is for the register to reside in the pad. Fast
> clock to output delays depend on this.
> 
> Any helpful suggestions on how to get the registers moved into the pads
> would be greatly appreciated. I prefer not to resort to manual instantiation
> of any components.
> 
> Best regards,
> Jamie Sanderson
Article: 18882
Subject: Re: Virtex: Getting flip-flops into the pads
From: bob@nospam.thanks (Bob Perlman)
Date: Fri, 19 Nov 1999 23:33:12 GMT
Links: << >>  << T >>  << A >>
Hi - 

On Fri, 19 Nov 1999 17:31:19 -0500, "Jamie Sanderson"
<jamie@nortelnetworks.com> wrote:

>Greetings;
>
>I'm getting my feet wet with Virtex, after having used the 4000 series for a
>few years.
>
>In the past, I've always stayed away from manually instantiating components,
>mostly because the code is less readable and portable. This has worked well
>with the 4000 parts when it comes to automatic inference of the startup
>block and usage of flip-flops in the I/O blocks. Now that I've started
>working with Virtex, neither of these works as it once did.
>
>I've read the application notes on the Xilinx site concerning the startup
>block and Synplify (the synthesis tool I'm using). Answer #4034 makes it
>clear that the startup block won't be instantiated automatically by this
>tool under any circumstances (even when force GSR is turned on???).
>
>http://www.xilinx.com/techdocs/4034.htm
>
>Moving on to the bigger problem... Top-level signals which are registered
>(either inputs or outputs) aren't being clocked in the pad. I've checked
>this using the FPGA editor. The pads are only being used as IBUF or OBUF.
>The registering of the signal occurs inside a CLB. What I want, and what
>used to happen automatically, is for the register to reside in the pad. Fast
>clock to output delays depend on this.

I encountered the same problem when synthesizing Verilog-based Virtex
designs with Synplicity.  When running map, include the -pr b switch
on the command line.  (I'm not sure what to do if you run Design
Manager, since I never use it.)  For more information on this switch,
refer to the map section of the Development System Reference Guide.  

Take care,
Bob Perlman

-----------------------------------------------------
Bob Perlman
Cambrian Design Works
Digital Design, Signal Integrity
http://www.best.com/~bobperl/cdw.htm
Send e-mail replies to best<dot>com, username bobperl
-----------------------------------------------------
Article: 18883
Subject: Re: Virtex: Getting flip-flops into the pads
From: simon_g@hotbot.com (Simon Goble)
Date: 19 Nov 1999 16:09:29 PST
Links: << >>  << T >>  << A >>
Hi Jaimie,

In the Design Manager look under the <Design><Options:Implementation:
Edit Options..> dialog under the <Optimize and Map> tab and set the
'Pack I/O Registers/Latches into IOBs for:' to 'Inputs and Outputs'.

Then, if you are using Foundation/Alliance 2.1, download the latest
service pack and install it  (good thing the weekend is coming-up :-).

This last step will, among other things, insure that inverters in the
IOBs will remain inverters... grrr!

Hope this helps,

++Simon Goble

(Remove the '_' in the return address to reply)

On Fri, 19 Nov 1999 17:31:19 -0500, "Jamie Sanderson"
<jamie@nortelnetworks.com> wrote:

>Greetings;
>
>I'm getting my feet wet with Virtex, after having used the 4000 series for a
>few years.
>
>In the past, I've always stayed away from manually instantiating components,
>mostly because the code is less readable and portable. This has worked well
>with the 4000 parts when it comes to automatic inference of the startup
>block and usage of flip-flops in the I/O blocks. Now that I've started
>working with Virtex, neither of these works as it once did.
>
>I've read the application notes on the Xilinx site concerning the startup
>block and Synplify (the synthesis tool I'm using). Answer #4034 makes it
>clear that the startup block won't be instantiated automatically by this
>tool under any circumstances (even when force GSR is turned on???).
>
>http://www.xilinx.com/techdocs/4034.htm
>
>Moving on to the bigger problem... Top-level signals which are registered
>(either inputs or outputs) aren't being clocked in the pad. I've checked
>this using the FPGA editor. The pads are only being used as IBUF or OBUF.
>The registering of the signal occurs inside a CLB. What I want, and what
>used to happen automatically, is for the register to reside in the pad. Fast
>clock to output delays depend on this.
>
>Any helpful suggestions on how to get the registers moved into the pads
>would be greatly appreciated. I prefer not to resort to manual instantiation
>of any components.
>
>Best regards,
>Jamie Sanderson
>
>

Article: 18884
Subject: Re: Virtex: Getting flip-flops into the pads
From: simon_g@hotbot.com (Simon Goble)
Date: 19 Nov 1999 16:30:49 PST
Links: << >>  << T >>  << A >>
Hi Jaimie,

In the Design Manager look under the <Design><Options:Implementation:
Edit Options..> dialog under the <Optimize and Map> tab and set the
'Pack I/O Registers/Latches into IOBs for:' to 'Inputs and Outputs'.

Then, if you are using Foundation/Alliance 2.1, download the latest
service pack and install it  (good thing the weekend is coming-up :-).

This last step will, among other things, insure that inverters in the
IOBs will remain inverters... grrr!

Hope this helps,

++Simon Goble

(Remove the '_' in the return address to reply)

On Fri, 19 Nov 1999 17:31:19 -0500, "Jamie Sanderson"
<jamie@nortelnetworks.com> wrote:

>Greetings;
>
>I'm getting my feet wet with Virtex, after having used the 4000 series for a
>few years.
>
>In the past, I've always stayed away from manually instantiating components,
>mostly because the code is less readable and portable. This has worked well
>with the 4000 parts when it comes to automatic inference of the startup
>block and usage of flip-flops in the I/O blocks. Now that I've started
>working with Virtex, neither of these works as it once did.
>
>I've read the application notes on the Xilinx site concerning the startup
>block and Synplify (the synthesis tool I'm using). Answer #4034 makes it
>clear that the startup block won't be instantiated automatically by this
>tool under any circumstances (even when force GSR is turned on???).
>
>http://www.xilinx.com/techdocs/4034.htm
>
>Moving on to the bigger problem... Top-level signals which are registered
>(either inputs or outputs) aren't being clocked in the pad. I've checked
>this using the FPGA editor. The pads are only being used as IBUF or OBUF.
>The registering of the signal occurs inside a CLB. What I want, and what
>used to happen automatically, is for the register to reside in the pad. Fast
>clock to output delays depend on this.
>
>Any helpful suggestions on how to get the registers moved into the pads
>would be greatly appreciated. I prefer not to resort to manual instantiation
>of any components.
>
>Best regards,
>Jamie Sanderson
>
>

Article: 18885
Subject: Synplify vs. FPGA Compiler II (v3.3)
From: arafeeq@my-deja.com
Date: Sat, 20 Nov 1999 00:40:05 GMT
Links: << >>  << T >>  << A >>
Hello!

We are evaluating the above two Synthesis tools for our FPGA and ASIC
design. Anybody who has used these tools could you please answer
following question.

Which one would be better of the two. Please note that our design will
be 250K+ gates. And FPGA would be Xilinx's virtex device.


Thanks
Best Regards,

Abdul Rafeeq.


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 18886
Subject: Re: How many bits in an FPGA bitstream?
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Fri, 19 Nov 1999 16:59:42 -0800
Links: << >>  << T >>  << A >>
On Fri, 19 Nov 1999 18:10:35 +0100, Luis Yanes
<melus@esi.us.spamno.es> wrote:


|I was just wondering if for the larger parts would worth to compress
|the bitstream, trading configuration file size by configuration speed,
|decompressing on the fly.
|
|The .bit files compress about 50% with zip or other archiver.
|
|73's de Luis


Luis,

I just browsed a .RBT file for an XCS20 design we're currently using,
and it's mostly 1's, generally in long runs. So some fast and simple
compression/decompression algorithm should be possible... might be
useful in a situation with big FPGAs and limited storage.

John


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

"If anybody ever marries you, it will be for the pleasure 
 of hearing you talk piffle," said Harriet, severely.
Article: 18887
Subject: FPGA Compiler II Altera Edition vs. FPGA Express Xilinx
From: adyer@enteract.com (Andrew M. Dyer)
Date: 20 Nov 1999 01:11:52 GMT
Links: << >>  << T >>  << A >>
I am contemplating using FPGA Compiler II Altera Edition with an "Apex" device 
or FPGA Express and a "Virtex" on an upcoming project.  The original source
code is for an ASIC synthesized with Design Compiler.  The goal is to implement
the FPGA version with as few changes to the source as possible and to accurately
reflect the ASIC functionality.

Has anyone compared the output of these two tools?  Any other comments
about either?  How about their handling of synthesis hints and scripts
from design compiler?

The design is intended to be an ASIC emulator to allow me to shake out the
design and give the s/w folks real hardware in system to play with while I
ready the final tape for fab.  It's not particularly fast (<25 MHz)
for most of it although a small portion of the design runs at 2x that.
-- 
Andrew Dyer <adyer@enteractDOTcom>

Where do you want to go today?
Nevermind, you're coming with us.
Article: 18888
Subject: Xilinx FPGA Editor...does it really work?
From: "Austin Franklin" <austin@dark88room.com>
Date: 20 Nov 1999 01:29:57 GMT
Links: << >>  << T >>  << A >>
I have a Virtex design, I just wanted to add a damn pin to, and for the
life of me, even following the documentation..I just can't get it to work. 
I want to add the SR pin of a CLB to an existing net...and it asks me for
the name of the net...and I type it, and it says it already exists...which
is true...but duh, it's what I want.

Also, I tried editing the equations in the CLB, and I can put in 0 or 1,
but not F4 ANYTHING but 0 or 1.

Is this tool just sadly broken, or just too obtuse for a somewhat
intelligent 12 year Xilinx veteran to use?  I never had this kind of
difficulty with the non-NeoCAD based editor...

Any help would be appreciated!

Article: 18889
Subject: Re: How to use GSR-net in Virtex?
From: Ray Andraka <randraka@ids.net>
Date: Fri, 19 Nov 1999 21:42:24 -0500
Links: << >>  << T >>  << A >>
Has anyone out there found a way to do a power on initialize in simulation  for
the Virtex ff primitives with the sync set/reset?   I've successfully used FDC's
instead of FD's and FDCE's instead of FDE's and driven the async reset with an
ROC component for FF's that don't need the direct sync set/reset, but that won't
work for the FDR or FDS primitives.

Oh, why instantiate primitives you ask?  It's because I'm putting together some
hand placed macros for pieces I use alot --things like filter slices and such
that I really don't want to hand place in the floorplanner every time they are
instantiated.  In these cases, the careful and floorplanning gives a performance
boost from 93 MHz to 154 MHz in a -4 part.

Andy Peters wrote:

> Austin Franklin wrote in message <01bf3240$f071f880$207079c0@drt1>...
>
> >It shouldn't be any different to do reset 'correctly' for an HDL design or
> >a schematic design, so I will ignore any problems that may exist with using
> >HDLs.  This is an architecture issue, not a tool issue.
>
> Well, you can instantiate the GSR if you like, or you can let the tool do it
> for you.  Me?  I prefer to let the tool instantiate GSR.  Makes the code a
> bit more portable, too, but that's a detail.
>
> >How can you say intentionally adding a reset to EVERY flop in the design is
> >not tedious?  Adding code to every instance of a flip flop in the design is
> >certainly extra work.
>
> Not, not really.  Writing:
>
>     flop : process (clk, reset)
>     begin
>         if reset = '1' then
>             blah <= '0';
>
> is not too difficult.  In fact, emacs conveniently does it for me.  It also
> has the major advantage of letting the simulation match the reality (i.e.,
> at the beginning of time, all flops are reset), and I don't have to deal
> with the xilinx simulation models.  My test benches assert that reset line
> at the beginning of time, and never after that.  It's only for power-on
> reset.
>
> It might be more difficult (read: time-consuming, tedious) in a schematic to
> have to connect the reset net to the async set/reset of every flop; placing
> the startup symbol relieves you of that necessity.  Then again, you've gotta
> hook up the clock signal to every flop.
>
> >How is it necessary?  If the GSR resets every flop, and is on a global
> >dedicated net that doesn't even take up any resources (that can be used for
> >something else), and meets timing and operational requirements?
>
> If you write the code as above, and make sure that all of the flops have an
> async reset signal in the sensitivity list, any tool worth a damn at the end
> of 1999 should infer GSR, which is what we want.  FPGA Express and
> Synplicity do.  In fact, if you screw up and forget to reset one of the
> flops, FPGA Express complains and says that it won't infer GSR.  So, of
> course it's a PITA to go through the reports and find the flops that you
> forgot to reset, but I usually find those sorts of mistakes in pre-synthesis
> simulation.  There tends to be big Us or Xs and red lines in the wave window
> until the flop is explicitly set or cleared.
>
> >What are you talking about power on reset?  You don't have to do anything
> >for power on reset, it is inherent in the configuration process.  The data
> >sheet says (and I quote):
>
> Yup, read it many times. I know that the startup sequence after powerup
> asserts GSR and resets all of the flipflops that it's connected to.
> However, for simulation convenience, it's nice to have a signal the test
> bench can assert for power-on reset.
>
> >Now, on creating a 'special' net for use as a reset (instead of using the
> >inherent GSR).  The Virtex spec says the delay from GSR to XQ/YQ is under
> >10ns.  You say you assert your RESET to the part synchronously, so as long
> >as your clock frequency is not > 100MHz, you will not have any problems
> >using the dedicated global reset, and therefore, is unnecessary to do it
> >using non-dedicated resources in this regard.
>
> Perhaps I wasn't clear.  By "synchronous reset," I meant something like a
> counter's synchronous clear signal that is generated by some other logic.  I
> don't mean that the sync reset is intended to reset the entire chip.
>
> For instance,
>
>     count : process (clk, reset) is
>     begin
>         if reset = '1' then
>             counter <= 0;    -- reset asserted at beginning of time
>         elsif rising_edge(clk) then
>             if clear = '1' then
>                 counter <= 0; -- sync "clear" asserted by other logic
>             elsif enable = '1' then
>                 counter <= counter + 1
>             end if;
>         end if;
>     end process count;
>
> Clearly, the counter's "clear" signal must meet timing, as does the "enable"
> signal, and the counter itself.  Perhaps calling the "clear" signal a reset
> is a misnomer, even though it's function is to reset a bunch of flipflops.
>
> >If you have an asynchronous reset, then all bets are off with either
> >method, no matter how low your RESET delay and/or skew is inside your part,
> >you stand a chance of having some of the chip come out of RESET on a
> >different clock edge...so you have to design accordingly, which is not too
> >tough to do, but still does not warrant not using the GSR.
>
> >
> >So, it would also appear that using anything aside from the dedicated GSR
> >would not give you any benefit (except under very specific conditions), and
> >therefore, at least for my designs, unnecessary.  And given the extra
> >resources it would use, I would also call it 'wrong'.
>
> Again, my async (GSR) reset is only used at power-up; all other flops are
> set or reset synchronously as required by the design.
>
> >I would appreciate it if you would post some 'facts' as to WHY creating
> >your own RESET signal, instead of using the dedicated GSR RESET signal, is
> >somehow beneficial.
>
> Facts are above, counselor.
>
> --
> -----------------------------------------
> Andy Peters
> Sr Electrical Engineer
> National Optical Astronomy Observatories
> 950 N Cherry Ave
> Tucson, AZ 85719
> apeters (at) noao \dot\ edu
>
> "Creation Science" is oxymoronic.



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 18890
Subject: Re: Synplify vs. FPGA Compiler II (v3.3)
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Fri, 19 Nov 1999 19:55:05 -0800
Links: << >>  << T >>  << A >>
I tried compiling my 25K(FPGA)gates with FPGA express and had Synplicity  do
it with Symplify.  It was compiled into XC4020XLA and XCV50.  Timing
requirement was 40MHz. It was a classic "logic" design with big 1-hot state
machines, a big internal 3-state bus, a bunch of ram registers, counters, an
incrementer, etc.  No big arithmetic elements.   Symplify produced a little
faster (44MHz Vs 40MHz) but noticeably larger design than FPGA express.  I
haven't really gone back to try to figure out why it was larger, I just
decided I wouldn't buy Symplify at this time.  In addition, my code
uncovered some Symplify bugs.  (but in all fairness, there were some
Synopsys work-arounds included also).

Synplicity people said that their tool generally gave faster designs at the
expense of some size.  For me the difference was 80% of an XCV50 Virtex for
FPGA Express Vs 116% for Symplify (wouldn't fit). They gave no further
explanation, and no suggestions about how to make it get better area
results.

You need to recognize that Synopsys has come a long ways since some of the
evaluations that people talk about here (but the GUI still and always will
suck).

But all of the tools have their limitations and stress-points.  I guarantee
that whatever tool you choose, if you are really picky about your results,
you will be pissed at some point.  For example, Symplicity (at some point in
the past) wouldn't deal well with greater than 12 state 1-hot machines, and
Synopsys (at some point, and maybe still) decided they would change one of
the states to a 0-hot state caus' they felt like it.  Many people would
never notice since they passed functional vectors.

If by some chance you are happy with the results, just wait for the next
upgrade.

Bruce

arafeeq@my-deja.com wrote in message <814ql5$i5m$1@nnrp1.deja.com>...
>Hello!
>
>We are evaluating the above two Synthesis tools for our FPGA and ASIC
>design. Anybody who has used these tools could you please answer
>following question.
>
>Which one would be better of the two. Please note that our design will
>be 250K+ gates. And FPGA would be Xilinx's virtex device.
>
>
>Thanks
>Best Regards,
>
>Abdul Rafeeq.
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.


Article: 18891
Subject: Maybe this will help Xilinx Service Pack Downloads
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Fri, 19 Nov 1999 20:06:28 -0800
Links: << >>  << T >>  << A >>
I just downloaded an FTP manager called Gozilla.  It's free, and it
implements the FTP restart capability.  Has a lot of cool features, but
restart and free are my favorites.  I haven't used it to download a service
pack yet, so I'm not sure if Xilinx will allow restart.

Anyway, just trying to help

bruce


Article: 18892
Subject: Re: implementing TCP/IP on PLD
From: email@inter.net
Date: Fri, 19 Nov 1999 22:11:16 -0800
Links: << >>  << T >>  << A >>
OK, let's set the record straight:

A full-featured TCP/IP stack has been done in an FGPA.  A pair of Xilinx
4044's, actually.

It was built on a PCI card; the processor could send an entire web page
to the card, then essentially say "go", and the FPGA's would do _all_
the rest; ACKs, retries, etc.  There was no CPU core.

The design still exists, and would probably be for sale to the right
parties; just don't expect it to be anywhere near 'cheap'.  Probably on
the same scale as an ARM IP license.

Sorry I can't say more; I signed an NDA before I worked on it.


Dirk Bruere wrote:
> 
> Jamie Lokier <spamfilter.nov1999@tantalophile.demon.co.uk> wrote in message
> news:m2ogctdoqy.fsf@pcep-jamie.cern.ch...
> > Austin Franklin writes:
> > > You can not implement a TCP/IP stack in just a PLD, there simply aren't
> > > enough gates, so you must not mean PLD, but something else...possibly
> > > microprocessor, FPGA.
> >
> > I heard it's been done on an FPGA, and not an especially large one either.
> 
> Not without a CPU core, AFAIK.
> 
> Dirk
Article: 18893
Subject: Re: WHERE can I find xc9536_v2.bsd??!
From: "h.f." <heinrich.f@t-online.de>
Date: Sat, 20 Nov 1999 08:52:00 +0100
Links: << >>  << T >>  << A >>
Download the xc9500.zip from http://www.xilinx.com/support/sw_bsdl.htm.
The zip-file contains also the xc9536_v2.bsd that you have to copy into
the appropriate directory of the Xilinx Foundation Software. I`m sure it
will work.

heinrich.f
Article: 18894
Subject: Re: orcad synthesis for simplepld
From: "Tom Meagher" <tomm@icshou.com>
Date: Sat, 20 Nov 1999 02:04:12 -0600
Links: << >>  << T >>  << A >>
<snip>
>curious about how common a problem this is. Is VHDL synthesis generally
worse
>than old ABEL/CUPL/Palasm synthesis?
>Or is it just that little PLDs are so unsexy that no-one bothers much
>developing the tools?
Graham,
I suspect that this is an Orcadism.  Some years ago Orcad was held in high
regard, with a widely used product of good quality.  In the last 5 years,
since the belated introduction of their Windows product line, I've lost all
faith in their ability to deliver a useable piece of software, despite the
fact that their hearts may be in the right place.  Perhaps sooner or later
they may get their act together.  I haven't used version 9.  Version 7.1,
which you refer to, I found to be a complete disaster.

You could post your code, and I could run it through Exemplar, Synplify, or
Maxplus, and I'm sure it would come out fine.  Certainly as good as Abel.  I
don't do much PLD stuff, but I do have a little 5032 design that is written
in behavioural VHDL and synthesizes great with Synplify.

It really is too bad about Orcad.  In the last days of DOS, they ruled!

Tom Meagher
Houston TX




Graham Seaman wrote in message <382df594@ant.wmin.ac.uk>...
>I wrote:
>: > I have a little behavioural VHDL FSM which analyzes ok; when I try to
>: build
>: > it  Orcad Express generates an error message telling me I have too many
>: > product terms for a couple of rows. On inspecting the vhdl netlist
>: > its generated, there are actually not many PTs in the expressions
>: > its complaining about - well within the powers of a 22V10!
>: > Is there a common user error which could generate this? Or is this
>: > a known problem for which a patch is available?  (I have v. 7.1)
>: >
>: > Thanks for any advice,
>: >
>: > Graham Seaman
>: >
>
>OK, I found the problem (with some help ;-). The error message itself
>is misleading: its actually complaining because the registers used for
>state bits in an FSM haven't been assigned pins [so ANY PTs would be too
many
>in this case]. This is because I went from a behavioural (case-statement)
>style design for the FSM, and as far as I can see means that I can't use
>this style of design for state machines going into PLDs and have to revert
>to hand minimisation. Since this must be one of the most common
applications
>for PLDs, and since IIRC even ABEL used to be able to handle this, I'm now
>curious about how common a problem this is. Is VHDL synthesis generally
worse
>than old ABEL/CUPL/Palasm synthesis?
>Or is it just that little PLDs are so unsexy that no-one bothers much
>developing the tools?
>
>Graham
>
>


Article: 18895
Subject: Re: Virtex: Getting flip-flops into the pads
From: a@z.com
Date: Sat, 20 Nov 1999 08:36:52 -0500
Links: << >>  << T >>  << A >>
Hi Jamie,

Try using port attributes in your VHDL code. The following constructs work with
Synplify targeting Virtex:

attribute xc_pullup : boolean;
attribute xc_pulldown : boolean;
attribute xc_fast : boolean;
attribute xc_ioff : boolean;
attribute xc_pullup of <PortName> : signal is true;
attribute xc_pulldown of <PortName> : signal is true;
attribute xc_fast of <PortName> : signal is true;
attribute xc_ioff of <PortName> : signal is true;

Replace <PortName> with the port name of your choice. You should insert these
lines in your top entity definition, after the port list but before "end
<EntityName>;".

The Xilinx place&route tools also have an option for allowing FFs in the IOBs
that must be turned on (I think it is off by default).

Catalin Baetoniu

Jamie Sanderson wrote:

> Greetings;
>
> I'm getting my feet wet with Virtex, after having used the 4000 series for a
> few years.
>
> In the past, I've always stayed away from manually instantiating components,
> mostly because the code is less readable and portable. This has worked well
> with the 4000 parts when it comes to automatic inference of the startup
> block and usage of flip-flops in the I/O blocks. Now that I've started
> working with Virtex, neither of these works as it once did.
> ...

Article: 18896
Subject: Re: Xilinx FPGA Editor...does it really work?
From: a@z.com
Date: Sat, 20 Nov 1999 09:05:15 -0500
Links: << >>  << T >>  << A >>
Hi Austin,

First use File/Main Properties to turn the Edit Mode to Read Write (it is Read
Only by default).

Then zoom in to your CLB (Ctrl-Right Click - and by the way zoom out is
Shift-Ctrl-Right Click!) and select your CLB pin. Then find your net in the
All Nets List (you can sort them by name) and Shith-Click to select it (if you
just Click the pin will be deselected). Press the add button and wait. Then
wait some more and when you least expect it your pin will be connected to that
net. Of course, you must first configure the CLB pin and then add it to the
net, otherwise it will just give you an error. You can also add multiple pins
to a net this way (using Shift-Click).

Now for the CLB equation problem. Select the CLB, press the editblock button
and in the Block Editor window the F= toolbar button. Edit Feqn and Geqn and
press the Save Changes and Closes Window toolbar button. It works for me.

By the way, what I have described is valid for the M2.1i FPGA Editor, the
M1.5i EPIC Design Editor, of NeoCAD origin, although similar is a different
beast (which never realy worked). The M2.1i version is a complete rewrite and
crashes less. I agree that the user interface is a bit strange.

Catalin Baetoniu

Austin Franklin wrote:

> I have a Virtex design, I just wanted to add a damn pin to, and for the
> life of me, even following the documentation..I just can't get it to work.
> I want to add the SR pin of a CLB to an existing net...and it asks me for
> the name of the net...and I type it, and it says it already exists...which
> is true...but duh, it's what I want.
>
> Also, I tried editing the equations in the CLB, and I can put in 0 or 1,
> but not F4 ANYTHING but 0 or 1.
>
> Is this tool just sadly broken, or just too obtuse for a somewhat
> intelligent 12 year Xilinx veteran to use?  I never had this kind of
> difficulty with the non-NeoCAD based editor...
>
> Any help would be appreciated!

Article: 18897
Subject: Re: implementing TCP/IP on PLD
From: "Dirk Bruere" <artemis@kbnet.co.uk>
Date: Sat, 20 Nov 1999 14:56:18 -0000
Links: << >>  << T >>  << A >>

<email@inter.net> wrote in message news:38363B84.74B@inter.net...
> OK, let's set the record straight:
>
> A full-featured TCP/IP stack has been done in an FGPA.  A pair of Xilinx
> 4044's, actually.
>
> It was built on a PCI card; the processor could send an entire web page
> to the card, then essentially say "go", and the FPGA's would do _all_
> the rest; ACKs, retries, etc.  There was no CPU core.
>
> The design still exists, and would probably be for sale to the right
> parties; just don't expect it to be anywhere near 'cheap'.  Probably on
> the same scale as an ARM IP license.
>
> Sorry I can't say more; I signed an NDA before I worked on it.
>

Well, another lost opportunity for both of us.
My port of TCP/IP is now in production with thousands being made. I would
rather have just bought the stack in chip form and interfaced it like a
normal IC.

Dirk


Article: 18898
Subject: Re: Xilinx FPGA Editor...does it really work?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 20 Nov 1999 10:01:29 -0500
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
> 
> I have a Virtex design, I just wanted to add a damn pin to, and for the
> life of me, even following the documentation..I just can't get it to work.
> I want to add the SR pin of a CLB to an existing net...and it asks me for
> the name of the net...and I type it, and it says it already exists...which
> is true...but duh, it's what I want.
> 
> Also, I tried editing the equations in the CLB, and I can put in 0 or 1,
> but not F4 ANYTHING but 0 or 1.
> 
> Is this tool just sadly broken, or just too obtuse for a somewhat
> intelligent 12 year Xilinx veteran to use?  I never had this kind of
> difficulty with the non-NeoCAD based editor...
> 
> Any help would be appreciated!

I think Catalin gave you some good advice. I believe the procedure you
were using will let you add the pin to a new net. Since the net you
typed exists, it would not clobber the existing net. 

The tool was protecting you from yourself... AND being very obtuse. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 18899
Subject: Re: Why not Lucent ORCA FGPAs?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Sat, 20 Nov 1999 10:18:49 -0500
Links: << >>  << T >>  << A >>
Don Husby wrote:
> 
> An anonymous poster (via Rickman) wrote:
> > I have picked the Lucent ORCA FPGAs for the board I am currently
> > building due to IO count, part cost and support. I have noticed that
> > there are not many people discussing these devices in this newsgroup,
> > which I assume is because there are not a lot of people using them. Can
> > I ask why Xilinx parts are preferred over the Lucent devices? Other than
> > inertia, why did you pick the Xilinx devices?
> 
> I started using the Orca parts many years ago after buying Neocad which,
> at the time, supported both Xilinx and Orca parts.  I found that the Orca
> parts had better performance, more pins, and were cheaper.  I think that
> is still true today for Orca 2x series parts vs. Xilinx 4x.
> 
> The two big architectural advantages that Orca 2x has are:
>  FE-Mux into each flip flop can be used in many cases as an extra logic input.
>  Large numbers of tristate lines running vertically and horizontally.
>  (There are 2 Tbufs per LUT in the orca part).
> 
> However, the OR2x lacks I/O flip flops and also doesn't have a carry
> structure as flexible as the X4K chips.
> 
> The Orca 3T series has made some improvements over the OR2x.
> It now has I/O Flip-Flops.  It's carry structure appears to be more
> flexible, but the software doesn't suport it.  (Xilinx has gone the other
> way, and made theirs less flexible).  Lucent also added a flip-flop to the
> carry chain, making it more efficient for pipelined arithmetic, and for
> implementing the 5-bit counters needed to address their 32-word RAMS.
> 
> The OR3T has only 1 Tbuf per LUT, but still has horizontal and vertical
> tristate lines as well as horizontal and vertical carry chains.  (Virtex
> has only vertical carry chains and horizontal tristate lines.  It has 0.5
> Tbuf per LUT.)
> 
> Lucent has also improved its memory architecture.  It uses 2 LUTS to
> implement a 32x1 dual-port memory, while Virtex loses a factor of 2 by
> using 2 Luts to make a 16x1 dual-port RAM.
> 
> Even with its apparent architectural advantages, the OR3T part doesn't do
> as well as Virtex parts for the designs that I've tested.  It appears that
> the synthesis software (Leonardo Spectrum) does a much better job for
> Virtex parts than for OR3T parts.
> 
> --
> Don Husby <husby@fnal.gov>             http://www-ese.fnal.gov/people/husby
> Fermi National Accelerator Lab                          Phone: 630-840-3668
> Batavia, IL 60510                                         Fax: 630-840-5406

Thanks for the info. I used the Lucent parts when they first came out.
The software was just short of unusable and they quickly dropped their
inhouse package and made Neocad the factory supplied software. But I was
done by then and never got around to working with the Neocad SW much. 

I think you have a good handle on much of the architecture. The IO FFs
are not just there, but they will support 0 hold time (without adding
delays) if you use the special clock pins. This is a big improvement in
the faster systems being used today. The 2T family was designed at a
time when speeds were much slower and the 0 hold time was not such an
issue. So a little extra delay getting to the FFs from the pins didn't
seem to be such a big deal. 

I am not clear about saying the software doesn't support the "flexible"
carry chain. I have done a bit of testing with counters and such and
found that I can place them not only vertical or horizontal, but around
corners! The only requirement for carry chains is to keep the PLCs
adjacent. I assume that you mean the synthesis software doesn't use this
feature? 

The poorer results of the synthesis wrt Xilinx designs is likely to be a
SW issue as you say. But I am using schematic for now. I just can't see
the real merits of HDL for much other than FSM work and that is where I
have the most trouble with an HDL! 

For now, I am very happy with the Lucent parts. I got 221 IOs in a 256
BGA package which is more than any of the Xilinx parts. The Xilinx
Virtex part (comparable to the OR3T parts) only gives 180 IOs in the 256
pin package!!! I don't know what happened with this part from Xilinx,
but they missed the pin count boat on this one. 

But then they have a new 280 pin CSP (they don't like me calling it a
BGA ;) that should give even more IOs in a smaller space and still be
routable with decent PCB design rules! But they only have it in the low
end series so far. So for the forseeable future I will be working with
the Lucent parts. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com


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