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 58525

Article: 58525
Subject: Re: Should I use ABEL?
From: Bertram Geiger <bgeiger@aon.at>
Date: Fri, 25 Jul 2003 10:48:38 +0200
Links: << >>  << T >>  << A >>
Chris Carlen schrieb:
> Hi:
> 
> I have read a little about ABEL, and it seems simpler than VHDL and 
> Verilog.  I need to learn an HDL quickly so I want to use the easiest 
> one, for starters.
> 
> I need to design relatively simple logic, usually just combinatorial 
> glue logic, but also some asynchronous logic.
> I wonder if ABELs simplicity might make it unable to express 
> asynchronous logic well, in which case I might be better off with a more 
> complex language.

its possible, but why asynchronous ?

...

for a really quick start and medium complexity like in CPLD design ABEL
seeems very convenient to me - i like it.
also nice for some glue logik with GAL like 22v10
simple description of state machines too
if you think about more complex FPGA design later, you might go right away
to VHDL/VERILOG

Bertram
-- 
Bertram Geiger <bgeiger@aon.at>
HTL-Bulme Graz, Austria


Article: 58526
Subject: Re: Should I use ABEL?
From: Mike Harrison <mike@whitewing.co.uk>
Date: Fri, 25 Jul 2003 10:18:26 +0100
Links: << >>  << T >>  << A >>
On Thu, 24 Jul 2003 13:25:53 -0700, Mike Treseler <mike.treseler@flukenetworks.com> wrote:

>Chris Carlen wrote:
>
>> I have read a little about ABEL, and it seems simpler than VHDL and 
>> Verilog.  I need to learn an HDL quickly so I want to use the easiest 
>> one, for starters.
>
>ABEL is moribund.
>
>If you are in a hurry, use schematics.
Depends what you want to do. 
I use CUPL (free version available from Atmel) - once you get the hang of the syntax it is very
quick to set stuff up that would take forever with a schematic. 
However both Abel and Cupl are aimed at small PLD/CPLD type devices and you need to have a good
understanding of the limitations of the target hardware to get the design to fit. 
If you are likely to be using larger devices, the investment in learning a more powerful and
portable language may be worthwhile.

Article: 58527
Subject: Re: Should I use ABEL?
From: "Maciek" <mkazula@elka.pw.edu.pl>
Date: Fri, 25 Jul 2003 12:20:37 +0200
Links: << >>  << T >>  << A >>
Hi,
    I have a lot experience in programming Altera's FPGA's that's why I use
AHDL. In my humble opinion it's very easy to learn this language, but if You
want Your designs to be independent of platform I suggest Verilog and
VHDL(in this order) to use. (Almost all CAD's recognizes them).
Have a  lot of fun,
Maciek




Article: 58528
Subject: GL85 synthesizable code
From: "Saeed Nari" <saeed@ce.sharif.edu>
Date: Fri, 25 Jul 2003 14:54:10 +0430
Links: << >>  << T >>  << A >>
Hi, VHDL friends
Does anyone have a synthesizable gl85, or i8085 VHDL
design? I have them, but can't synthesize with leonardo or synopsis.
Please reply to this address. Thank you a lot!



Article: 58529
Subject: XAPP058 SVF2XSVF converter problems
From: Egads <egadsNOJUNK@fnal.gov>
Date: Fri, 25 Jul 2003 07:34:23 -0500
Links: << >>  << T >>  << A >>

I'm trying to use/port the JTAG programmer in XAPP058, "Xilinx
In-System Programming Using an Embedded Microcontroller v3.0".

I use IMPACT to generate a SVF file.  The SVF file is generated
with no errors.  Next I run the SVF file through the SVF2XSVF
converter supplied with XAPP058.  When I try to run SVF2XSVF.exe
I get the following error:

Error  : Invalid SDR format [(]
[2svf.svf: line 8332]:[f]

I use the following command line:

svf2xsvf -d -fpga -i 2svf.svf -o 2svf.xsvf -a 2svf.txt

I'm running ISE 5.2.03.i

Anyone know why I'm getting errors ?  I've been trying to open a
"Hot Line" case on Xilinx's web site but it NEVER LETS ME IN.
When ever I try to log in I get:

> Greg, 
> Your request for access is already pending approval. Please
> allow 24 hours from your original request. 
> If you feel there has been an error, please contact
> websupport_sponsor@xilinx.com

I've waited a week and websupport_sponsor@xilinx.com has not gotten
back to me yet.

Thanks...


-- 
Greg Deuerling
Fermi National Accelerator Laboratory
P.O.Box 500 MS368  Batavia, IL 60510
(630)840-4629     FAX  (630)840-5406
Electronic Systems Engineering Group
Work: egads_AT_fnal.gov, remove '_AT_'

Article: 58530
Subject: Re: VHDL predefined constants
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Fri, 25 Jul 2003 22:49:24 +1000
Links: << >>  << T >>  << A >>
On Thu, 24 Jul 2003 18:43:58 -0400, rickman <spamgoeshere4@yahoo.com>
wrote:

>In C programming the compiliers define constants for the date and time
>and a lot of other things that are useful information to a program.  Do
>VHDL synthesis packages do the same thing?  

No.  I did suggest this to the committee a few years ago, but it never
got off the ground (probably on the grounds that it would have made
VHDL easier to use).

>I am looking for an
>indication of what tool is being used or what chip is being targeted so
>that instantiated components can be tailored for the brand and family of
>chip.  I am sure I am not the first person to think of this.  

We do a similar thing here, for similar reasons.

We define a common package containing a type which can be used to
describe the type of FPGA, e.g.

package pkg_fpga_family_type is

    type t_fpga_family is (
        FPGA_FAMILY_UNDEFINED,  -- don't use
        FPGA_FAMILY_VIRTEX_2,
        FPGA_FAMILY_VIRTEX_E
        -- add other types here
    );

end package pkg_fpga_family_type;


Each project (i.e. project = chip) contains a unique copy of another
package "pkg_global" that is used by all modules.  Pkg_global contains
a constant of a particular name of type t_fpga_family.

e.g. (in pkg_global)

  constant FPGA_FAMILY   : t_fpga_family := FPGA_FAMILY_VIRTEX_2;


Any module that wants to do fpga family specific stuff will contain
something like the following lines:

use work.pkg_fpga_family.all;
use work.pkg_global.all;

...


  foo : if FPGA_FAMILY = FPGA_FAMILY_VIRTEX_E generate
    -- do Virtex-E specific stuff

...

  bar : if FPGA_FAMILY = FPGA_FAMILY_VIRTEX_2 generate
    -- do Virtex-2 specific stuff


(It's also possible to pass the information in to the module via
generics instead of constants in packages.)


You quickly realise that VHDL really needs a "case-generate" and
"if-elsif-else generate" which (for some reason) were left out of the
'87, '93 and '00 standards.  There's a proposal that's likely to make
it into 200X though.


The next thing you probably should do is create wrappers for your low
level components (e.g. block rams) so that you don't ever instantiate
a "raw" block ram in your application code; you just instantiate the
wrapper.  The wrapper will hide all the details of fpga_family from
you.  When you want to add a new fpga_family value, you only have to
edit the wrapper.  (You can also include "value added" features such
as a selectable pipeline delay on the output, etc.)

This has an unexpected side-effect - you can easily add simulation
models to the wrappers (selected by a generic that's only set during
simulation) that behave the same way, but run faster.  We typically
get a 2:1 to 5:1 simulation speed up this way.  (The Xilinx Unisim
library uses VITAL and is *slooow* compared to an RTL simulation.)


I hope this helps.

Regards,
Allan.

Article: 58531
Subject: Quartus and memory initialization
From: "Maciek" <mkazula@elka.pw.edu.pl>
Date: Fri, 25 Jul 2003 14:53:20 +0200
Links: << >>  << T >>  << A >>
Hi,
    Maybe I lately spend too much time with computer and sleep too little so
I stopped thinking , but I have following problem.
I'm using now Altera Quartus Web Edition 3.0 free version in academic
project. In my project I use lpm ram component. When I used MaxPlus+II I was
able to specify Memory Initialization File(mif) during the simulation. Now
with Quartus I also can create mif files but I can't find out how to
associate them with memory components in my project. During the compilation
I obtain warning message: "Warning: Memory Initialization File or
Hexadecimal (Intel-Format) File for RAM is not specified -- setting initial
contents to 0" and that's all.
I don't know where is the problem - maybe in me, or maybe free version of
Quartus have some limitations.
Thank You for Your help,
Maciek




Article: 58532
Subject: Re: Quartus and memory initialization
From: "Maciek" <mkazula@elka.pw.edu.pl>
Date: Fri, 25 Jul 2003 15:01:26 +0200
Links: << >>  << T >>  << A >>
please, forgive me, it was so obvious...
Maciek




Article: 58533
Subject: Re: temux
From: "Patrick MacGregor" <patrickmacgregor@comcast.net>
Date: Fri, 25 Jul 2003 09:39:46 -0400
Links: << >>  << T >>  << A >>
I think you've asked this question before, perhaps a month or two ago.  As
with the last time, it isn't clear what you are trying to do.

Do you have 16 separate inputs at 16 MHz each?  If so, cramming 256 MHz
worth of data into a 155 MHz pipe is a neat trick, but not one a TEMUX can
do.  Or an FPGA for that matter.

You can cram 2 signals at 16 MHz into one DS3 rate signal, but 3 at 16 MHz =
48 MHz, and therefore won't fit.  Using this math, the best you could do is
cram 6 signals into 3 DS3's, which could fit into a 155M signal.  Without
doing much math, I think you can cram maybe 9 of these 16 MHz signals into a
concatenated 155M pipe.

But, then again, it isn't clear what you are trying to do or how you are
carving up the data.  Are you selecting some subset of the 16 inputs to feed
through the STM-1 pipe?  If so, how many max?  What is the clock tolerance
on the 16 MHz signals?

Can you provide any additional detail?


"Masoud Naderi" <naderimisc@yahoo.com> wrote in message
news:2ba3bbea.0307241443.3ba8845b@posting.google.com...
> Hi all,
> I want to use PMC-Sierra chipset for my STM-1 card. Input to this card
> is 16x16Mhz sync channels that comes from backplane. I can use
> PMC_TEMUX chip(pm8316) to make 3xDS3 PDH channel and feed them to
> PMC_SPECTRA chip (PM5342). But it seems using PMC_TEMUX chip is not
> cost saving and not suitable for this design, because TEMUX can do
> many things that wont use in this application. I think making DS3
> signals from backplane signals (16Mhz) can be done easely in FPGA, so
> bypassing TEMUX chip. It should be noted that single or multi E1
> channels should be extraced from our output STM-1 signal (for example
> from an ADM in SDH ring).
> Please help me in this regard.
> Regards.
> M. Naderi



Article: 58534
Subject: Re: XAPP058 SVF2XSVF converter problems
From: Chen Wei Tseng <chenwei.tseng@xilinx.com>
Date: Fri, 25 Jul 2003 08:56:37 -0600
Links: << >>  << T >>  << A >>
Egads,

You may want to make sure you have the latest build of iMPACT(5.2isp3)
and SVF2XSVF(5.11 build) converter. Also, you can contact the hotline by
phone as it's likely that you'll have to submit your files for further
investigation.

Regards, Wei
Xilinx Apps

Egads wrote:

> I'm trying to use/port the JTAG programmer in XAPP058, "Xilinx
> In-System Programming Using an Embedded Microcontroller v3.0".
>
> I use IMPACT to generate a SVF file.  The SVF file is generated
> with no errors.  Next I run the SVF file through the SVF2XSVF
> converter supplied with XAPP058.  When I try to run SVF2XSVF.exe
> I get the following error:
>
> Error  : Invalid SDR format [(]
> [2svf.svf: line 8332]:[f]
>
> I use the following command line:
>
> svf2xsvf -d -fpga -i 2svf.svf -o 2svf.xsvf -a 2svf.txt
>
> I'm running ISE 5.2.03.i
>
> Anyone know why I'm getting errors ?  I've been trying to open a
> "Hot Line" case on Xilinx's web site but it NEVER LETS ME IN.
> When ever I try to log in I get:
>
> > Greg,
> > Your request for access is already pending approval. Please
> > allow 24 hours from your original request.
> > If you feel there has been an error, please contact
> > websupport_sponsor@xilinx.com
>
> I've waited a week and websupport_sponsor@xilinx.com has not gotten
> back to me yet.
>
> Thanks...
>
> --
> Greg Deuerling
> Fermi National Accelerator Laboratory
> P.O.Box 500 MS368  Batavia, IL 60510
> (630)840-4629     FAX  (630)840-5406
> Electronic Systems Engineering Group
> Work: egads_AT_fnal.gov, remove '_AT_'


Article: 58535
Subject: Re: Use ICAp iwth a soft IP core to decompress!!!!
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 25 Jul 2003 07:58:13 -0700
Links: << >>  << T >>  << A >>
Symon,

No, I love the idea, and I have recommended it to the folks that do that kind of stuff.

Unfortunately, it goes in the same pile at all of the other IP requests, and then it gets looked at for
how it adds to the bottom line (we are a business, after all).

Like any other claim from the "competion," our first reaction is not "oh my, the sky is falling"
primarily because the claims are often inflated.  Rather, we look at the feature, and decide if it is
worth the effort/business to match/exceed it.

Austin

Symon wrote:

> Of course, use MicroBlaze! Good one, John, works for VirtexII and Pro.
> Does SpartanIII have ICAP? Can't see it in the datasheet I have. Any
> idea of the resource needed for a MicroBlaze and a UnZip program?
>    It seems to me that Xilinx might want to implement this for us.
> They get to use a known compression standard, Zip, supported by
> everybody's computer, so customers can see the likely compression
> ratio results.(Up to 5:1 according to Ray's post.) They can showcase
> their MicroBlaze, Partial Reconfiguration, ICAP. They beat their
> competition's 35% to 60% compression, using a soft, programmable,
> retrofittable solution which FPGAs are all about in the first place.
> What about it Austin? Are you worried about plunging sales of the
> config PROMs? ;-)
>         cheers, Syms.
>
> John Williams <jwilliams@itee.uq.edu.au> wrote in message news:<bfn953$bl7$1@bunyip.cc.uq.edu.au>...
> > Symon wrote:
> > > Austin,
> > >     Glad you like the idea. Out of curiosity I tried WinZipping some
> > > bit files and got >90% compression on my admittedly only 10% full V2
> > > design. So, I await the first freebie port of WinZip to VHDL or the
> > > PPC. I won't be holding my breath!!
> >
> > zlib builds cleanly for microblaze with mb-gcc - it would be very simple
> > to write a simple microblaze program to decompress a bitstream file.
> >
> > The trick would be interfacing the microblaze to ICAP and and pumping
> > the bits.  As long as the new (decompressed) bitfile didn't overwrite
> > the microblaze that was actually doing the decompression, you'd be off
> > and running.  If you eventually used the microblaze in your "final"
> > design then this would be quite a neat way to go.
> >
> > Regards,
> >
> > John


Article: 58536
Subject: Re: Use ICAp iwth a soft IP core to decompress!!!!
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 25 Jul 2003 08:07:45 -0700
Links: << >>  << T >>  << A >>
Symon,

I suppose we are in violent agreement on this issue (ie the soft core is a great solution).

We have already gone and asked "how much money/business do we get (incrementally) if we have bitstream
compression?"

Guess what?  It is pretty tiny.  So let me clue you in on something:  with the costs of memory always falling
like crazy, and the costs of developing anything reliable of high quality being always pretty high ($$$), what
do you think the probability of us releasing the soft core that unzips the bitstream?

Now, maybe next summer's interns....

If someone out there developed it, maybe someone would pay for the IP?

Heck, if someone really wants to do this for Spartan 3 (ie serious with business), email me directly, and I will
find out about the "hidden" features (if it is possible or not, and how much hacking is required).

Austin


Symon wrote:

> Hi Austin,
>     On the other hand, I'm sure every one of those 150k designers
> understands that compression ratios aren't guaranteed. It doesn't stop
> us all using .zip files, does it? Just another tool in the designer's
> armoury! Furthermore, Xilinx already offers bitstream compression on
> an unused frames basis, so I don't really follow your argument that
> Xilinx needs to give a compression guarantee before offering this
> feature?
>     So, doesn't the soft solution we're discussing here solve the
> arguments against providing better compression? I'm sure loads of
> folks would appreciate this feature. Why not get your marketing to ask
> some of them? Also, why not try running WinZip on some of the many
> sample designs you have, and let us know the results?
>     I guess a cynic might say that because vendor A started offering
> compression, the official vendor X stance is that it's not needed. Not
> me though, I trust you guys have our best interests at heart!! ;-)
>          All the best, Syms.
>
> p.s. I chuckled at the 'wonderful downloading experience' bit! Over
> the years my downloading experiences have often been somewhat less
> than 'wonderful'! Frustrating, temperamental, even infuriating! I
> guess I only remember the bad ones, I must admit things seem to have
> improved recently. Must go smoke my 'Done Pipe'! ;-)
>
> Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F1FF59D.BE7CA90D@xilinx.com>...
> > Ray,
> >
> > We routinely get folks who say they can compress a particular bitfile by 5:1 or even 10:1.
> >
> > Too bad that doesn't hold true for all bitfiles.
> >
> > As I have said before, if there was a good way to guarantee compression, we would have done it years ago.
> >
> > Let's see, we have ~150,000 bitstreams that are being developed right now at this moment.  Think about
> > it:  to remain a quality supplier we have to make every one of those 150,000 designers have a wonderful
> > (downloading) FPGA experience.  Just one flakey option bit in the bitgen, and the hotlines would meltdown.
> >
> > Austin
> >


Article: 58537
Subject: Re: Should I use ABEL?
From: Dennis McCrohan <dennis.mccrohan@xilinx.com>
Date: Fri, 25 Jul 2003 09:04:26 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> Chris Carlen wrote:
>
> > I have read a little about ABEL, and it seems simpler than VHDL and
> > Verilog.  I need to learn an HDL quickly so I want to use the easiest
> > one, for starters.
>
> ABEL is moribund.
>

Abel is very much alive, as part of our (free) Webpack and iSE products. We
have even made a few enhancements in the last few years, such as improved FSM
optimization.

However, it is only supported for targeting Xilinx CPLDs. So if you are doing
this for educational reasons, you probably want to go with one of the two "V"
languages - Verilog or VHDL (hint: of the two, Verilog is generally considered
to be the easier to learn, unless you happen to already know Ada).

There is a body of opinion, both inside and outside of Xilinx, that for
crafting tight, small CPLD designs, Abel is superior to VHDL/Verilog.
Semantically, it is much closer to an assembly language, allowing you to
specify exactly what you want your implementation to be.

An easy way to compare the languages is to look at the jc2 design examples
shipped with Webpack. It comes in Abel, VHDL, Verilog and schematic variants.

My $.02,

Dennis McCrohan
Xilinx CPLD S/W



Article: 58538
Subject: Re: Synplify syn_direct_enable doesn't work for me.
From: symon_brewer@hotmail.com (Symon)
Date: 25 Jul 2003 09:14:40 -0700
Links: << >>  << T >>  << A >>
Hi Jim,
      No worries! I'd be grateful if you let me know how you get on,
it's a useful feature!
                 thanks again, Syms.
"Jim Robinson" <jim@synplicity.com> wrote in message news:<42ZTa.28599$Nf.74228@sea-read.news.verio.net>...
> Hi Symon,
> 
> Sorry that is missed that.  I was focused on the problem flop and
> was not paying attention to the counter.
> 
> Since it appears that you have a work-around in place (toggle as
> std_logic_vector),
> I will shift my attention towards working with our development team to
> diagnose the bug and schedule a fix.
> 
> My appologies for not providing you with a more useful work around.  Let me
> know if you encounter any other difficulties.
> 
> Best Regards,
> Jim Robinson
> 
>

Article: 58539
Subject: Re: Reseting the whole thing
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 25 Jul 2003 09:17:13 -0700
Links: << >>  << T >>  << A >>
Global reset is obviously a good thing, but it also has a problem:
What happens after the trailing edge of global reset?
Cab you take away the global reset "simultaneously" from all affected
circuits, and if you cannot, what happens when one circuit stays in
reset a few clock ticks longer than the others ?
All Xilinx FPGAs have a built-in global reset that gets released at the
end of configuration, and that release can also automatically be
internally synchronized with the user clock. Inspite of this, at high
clock rates some state machines may need individually resynchronized
reset. This has been discussed in many threads in this ng.

Peter Alfke, Xilinx Applications

Article: 58540
Subject: Re: Altera Nios 3: Using Interface To User Logic Problem
From: kempaj@yahoo.com (Jesse Kempa)
Date: 25 Jul 2003 09:22:41 -0700
Links: << >>  << T >>  << A >>
Hi Yevgeny,

I can make two suggestions here. 

>
> How can I make NIOS to wait for the "ready" from the arbiter?
> I think I've tryed every signal there : "dataready", "dataready_n", etc...
> 

First, with regards to the current implementation you are attempting:
The key here is which signals Nios responds to for delaying or waiting
for a bus transaction. It sounds as if you're using a 'ready' signal
and connecting it to type 'dataavailable' (avalon signal type) in the
SOPC Builder wizard. The dataavailable signal, like its counterparts
'endofpacket' and 'readyfordata' are the three "Streaming" signals
supported by Avalon. As per the Avalon Bus Spec, not all masters heed
these 'streaming' signals. For example, the Nios CPU doesn't, while
the DMA controller does.

The simplest solution to your current implementation attempt is to use
a signal that Nios (and all avalon masters) must respond to: the
waitrequest signal. Waitrequest is just that. When a master attempts a
bus transfer with a slave, it is locked waiting until the slave
negates waitrequest. I would caution you to ensure that your logic
negates waitrequest, as a logical error that would leave it asserted
would hang the CPU (or any other master) attempting access.

>
> Or maybe there is a way to configure NIOSes SDRAM controller to support
> two NIOS CPUs instead of using that external arbiter?
> 

The second thing I can suggest, and would recommend, is to make use of
our own bus arbitration logic. You can in fact connect two (or more)
masters (two Nios', DMA, your own custom master, another
microprocessor) to any avalon slave, including the SDRAM controller.
The 'external' arbiter you refer to, our own Avalon bus logic,
automatically wires everything up. However, beyond this it also allows
you to balance the priority (using a fairness-based arbitration
scheme) for anytime more than 1 master requests the same slave. For
the case of two CPUs talking to shared SDRAM, I'd suggest giving each
an arbitration assignment high enough to allow several pipelined
accesses by each CPU, allowing higher throughput (perhaps 16/16,
32/32, or something similar). I suggest checking out Altera App note
189 for a brief overview of how this is implemented.

Please note that for optimal performance, I would also recommend that
you use the enhanced (SDR) SDRAM controller included with the Nios 3.0
(or higher) release.

Regards,

Jesse Kempa
Altera Corp.
jkempa at altera dot com

Article: 58541
Subject: Re: Reseting the whole thing
From: symon_brewer@hotmail.com (Symon)
Date: 25 Jul 2003 09:25:13 -0700
Links: << >>  << T >>  << A >>
Hi,
  The problem with a global reset can occur if, 
a) the reset is asynchronous
b) there are synchronous elements in the design clocked by clocks
different from the one that's synchronous with the reset

  If the global reset is cleared at the same time as, for example, a
flip flop is being clocked, then you might encounter metastability
problems, or state machines being initialised into illegal states.
  Try reading the TechXclusive by Ken Chapman on the Xilinx site
called "Get Smart About Reset (Think Local, Not Global)". He describes
it better than I can!
                Cheers, Syms.

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<f45Ua.3778$Si5.3166@newssvr22.news.prodigy.com>...
> I'm not disputing the need for reliable reset.  From what I've read on this
> N.G. the GSR approach does not seem to be the recommended way to go.
> 
> On my current design I implement an "intelligent" global reset module that
> issues reset signals to various portions of the design and verifies that the
> module being reset is OK before moving forward.  For example, the DCM's need
> to be checked for lock before allowing related modules to even think about
> intializing, much less operating.  I also have several modules that set a
> flag when their state machine enters the "RESET" or "INIT" state.  The reset
> generator looks for this flag as confirmation that the particular module is
> OK.  Since my design requires modules to be reset/released-from-reset in a
> specific sequence this works very well.  There are modules that have their
> own reset or startup requirements.
> 
> I guess I now think of an external reset signal as just another input that
> triggers actions (in my case a state machine) as opposed to the reset inputs
> of all the flip-flops within the FPGA.
> 
> Are you saying that it is OK to rely on a global reset signal that is
> directly connected to all flip-flops within the FPGA?  Again, reading
> through the N.G. archives the experts seem to agree on that this is
> potentially dangerous.
> 
> I only have experience with Xilinx Virtex II, so my field of vision is
> seriously impared.
> 
> 
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
> 
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"
> 
> 
> 
> 
>

Article: 58542
Subject: Re: Pricing question....
From: symon_brewer@hotmail.com (Symon)
Date: 25 Jul 2003 09:58:25 -0700
Links: << >>  << T >>  << A >>
If you ignore Trolls they usually go away!

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<IL4Ua.3776$3o5.1223@newssvr22.news.prodigy.com>...
> > seannstifler69@hotmail.com (Stifler) wrote:
> 
> ...
> >> Why are you vendors even on this board? Who believes all of your spew?
> ...
>

Article: 58543
Subject: Re: Pricing question....
From: "Neeraj Varma" <neeraj@cg-coreel.com>
Date: Fri, 25 Jul 2003 23:12:32 +0530
Links: << >>  << T >>  << A >>
history has shown price of the same part go down year over year, and there
is no fixed percentage you can attach since it depends upon a lot of
factors...and the price may become flat at certain point in time wherein the
part is considered "mature". How much time? Again, too many factors, and
pretty evident that this time is shrinking...and so is the time when an
end-product actually remains in demand...

always better to be able to embrace newer technologies to get a quantum cost
reduction...

--neeraj

"MS" <wpiman@aol.com> wrote in message
news:f0ddfdfb.0307231511.41556904@posting.google.com...
> Hi,
> So we are looking to implement some functionality that we have done in
> NPUs in the past into a Xilinx Virtex2Pro family (small space and less
> power).
>
> These parts are quite expensive right now (up to $1500 a piece).  Our
> build timeframe is starting next year, carrying out into 2006/2007.
> When you add up the cost of product- the budget is nearly consumed
> completely by the FPGAs.
>
> The question is how much do you usually expect FPGA prices to fall in
> a given year.  For example, would a guess of a 15% drop in the first
> year followed by a 30% fall in the second year be a good stab?  20% a
> year?  I just need to fill out some numbers to make some bean counter
> happy.  Anyone take a look at what has historical been the price
> drops?
>
> Thanks,
> M Scott



Article: 58544
Subject: Re: Reseting the whole thing
From: "..:: Gabster ::.." <gabsterblue@hotmail.com>
Date: Fri, 25 Jul 2003 14:32:12 -0400
Links: << >>  << T >>  << A >>
You guys are right, there's no need for an external reset on power up. Using
the GSR to reset my state machine and start the whole thing is the simple
solution.

thanks

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:uQ3Ua.3774$m%4.3163@newssvr22.news.prodigy.com...
> Why is it that you want to reset the FPGA after configuration?  For all
> intents and purposes it is coming out of reset after configuration.
>
> If you need to do so in order to wait for an event build that into a
startup
> state machine.
>
> If you need to guarantee that other portions of the board are ready you
can
> also build that into a startup state machine.
>
> If you need to ensure that certain flip-flops and logic come-up in a
> specific state you can do that through the bitmap itself.
>
> I've read quite a bit about global reset not being a reliable approach.
Do
> a Google search of this N.G. using "GSR".  Imagine flip-flops in different
> portions of the design coming out of reset at slighly different times.  Or
> maybe even flip-flops holding the state of a state machine.  I believe
I've
> experienced this first hand (not using GSR, but my own global reset) and
it
> wasn't fun to debug, it took longer than I care to admit to figure out
what
> was going on.
>
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_"  =  "martineu"
>
>
>
> "..:: Gabster ::.." <gabsterblue@hotmail.com> wrote in message
> news:Vy2Ua.10962$Fo3.164756@weber.videotron.net...
> > Hi,
> >
> >     I want to use a simple reset circuit to reset my FPGA, but I'm
unsure
> > how to handle it because of the PROM. The point is the PROM has to
program
> > the FPGA before the FPGA is reset. How the reset circuit could to be
> > implemented considering this. I was thinking about a reset circuit with
a
> > built-in delay, but I'm sure there's a easier way to do it.
> >
> > thanks,
> > Gabriel
> >
> >
>
>



Article: 58545
Subject: Re: Active Probe
From: symon_brewer@hotmail.com (Symon)
Date: 25 Jul 2003 11:43:40 -0700
Links: << >>  << T >>  << A >>
Here's a nice link:-
http://www.emcesd.com/1ghzprob.htm
Nice piccies!

Also :-
http://www.sigcon.com/
          HTH, Syms

"Peter C. Wallace" <pcw@freeby.mesanet.com> wrote in message news:<pan.2003.07.24.23.29.19.599163.15416@freeby.mesanet.com>...
> On Thu, 24 Jul 2003 16:04:20 -0700, Peter Alfke wrote:
> 
> > Howard Johnson once gave me a nice tip: Use a 50 Ohm cable driving a 50
> > Ohm-terminated input to the oscilloscope. Then solder a 470 Ohm resistor
> >  to the cable front end, and you have a 10:1 passive probe with GHz
> > bandwidth. Doesn't make the scope any faster, but avoids the loss of
> > bandwidth in the probe. You pay for it by throwing away a factor 10 in
> > sensitivity, and you load the circuit under test with 520 Ohm, but both
> > these restrictions are acceptable, most of the time...
> > 
> > Peter Alfke
> > ===================
> 
> 
> Plus 520 Ohms resistive load is a lot better for pulse fidelity than the 159
> Ohms capacitive reactance of a 10 PF scope probe at just 100 MHz...
> 
> PCW

Article: 58546
Subject: Re: Should I use ABEL?
From: Chris Carlen <crobc@BOGUSFIELD.earthlink.net>
Date: Fri, 25 Jul 2003 11:50:54 -0700
Links: << >>  << T >>  << A >>
Dennis McCrohan wrote:
> Mike Treseler wrote:
> 
> 
>>Chris Carlen wrote:
>>
>>
>>>I have read a little about ABEL, and it seems simpler than VHDL and
>>>Verilog.  I need to learn an HDL quickly so I want to use the easiest
>>>one, for starters.
>>
>>ABEL is moribund.
>>
> 
> 
> Abel is very much alive, as part of our (free) Webpack and iSE products. We
> have even made a few enhancements in the last few years, such as improved FSM
> optimization.
> 
> However, it is only supported for targeting Xilinx CPLDs. So if you are doing
> this for educational reasons, you probably want to go with one of the two "V"
> languages - Verilog or VHDL (hint: of the two, Verilog is generally considered
> to be the easier to learn, unless you happen to already know Ada).
> 
> There is a body of opinion, both inside and outside of Xilinx, that for
> crafting tight, small CPLD designs, Abel is superior to VHDL/Verilog.
> Semantically, it is much closer to an assembly language, allowing you to
> specify exactly what you want your implementation to be.
> 
> An easy way to compare the languages is to look at the jc2 design examples
> shipped with Webpack. It comes in Abel, VHDL, Verilog and schematic variants.
> 
> My $.02,


Thanks for the input.

A lot of conflicting responses.  It might be that the investment of 
effort to learn to do my relatively simple projects in ABEL, will not be 
wasted.  I can always look at one of the V languages later.

It is good that Webpack includes an example which is implemented in all 
four methods.  I will check it out.

Good day!


-- 
_____________________
Christopher R. Carlen
crobc@earthlink.net
Suse 8.1 Linux 2.4.19


Article: 58547
Subject: Re: Relative placement constraints in VHDL for Virtex multipliers
From: symon_brewer@hotmail.com (Symon)
Date: 25 Jul 2003 13:12:23 -0700
Links: << >>  << T >>  << A >>
Jack,
http://www.xilinx.com/xlnx/xweb/xil_tx_home.jsp

Relationally Placed Macros

          HTH, Syms.

bymanaar@hotmail.com (Jack Stone) wrote in message news:<6ba79926.0307250028.331f0d58@posting.google.com>...
> This question may have been asked before but ...
> 
> I often have timing problems when using virtex-II dedicated
> multipliers. After synthesis/P&R I have fixed these by looking at the
> placement with ISE floorplanner and then constraining the multipliers
> and their i/o registers to be packed as close together as possible.
> This requires too much effort for this lazy engineer. I must be
> possible to do this constraining in my VHDL code via attributes. How?
> Does anyone have a bit of example code?
> 
> I don't really want to place the multiplier in any certain spot,
> rather just make sure that the registers holding its input and
> catching its output will be placed in the adjacent slices...
> 
> Thanks in advance for your help.

Article: 58548
Subject: Re: temux
From: naderimisc@yahoo.com (Masoud Naderi)
Date: 25 Jul 2003 14:49:19 -0700
Links: << >>  << T >>  << A >>
Hi Andrew,
All 16Mhz signal on backplane have the same clock and frame sync.
signal, i.e. ALL of them are sync together with the same clock.
Anolog problem like jitter, crosstalk, skew or other things is not of
my concern, because they are solved in a different designing layer. In
my design layer ONLY chipset (functionality, cost, chipset reliability
and ...) is important.
My STM-1 card has two STM-1 (155M) Port. 8x16Mhz signal feed to each
port's chipset. Not all of time slots in 8x16Mhz go to output ports.
Some of them used for board and chipset housekeeping and remote
configurations.
I find the answer of my first question: Is it possible to make 3xDS3
signal from 8x16Mhz(SYNC) backplane channel by FPGA and feed them to
PMC_SPECTRA?
The answer: Yes, it is possible, DS3 framing in FPGA is not so hard
because all channels are synchronous together. In receive side from
PMC_SPECTRA FPGA must extract, for example 21xE1 signal from 3xDS3
lines, synchronize all of them to one clock signal and convert them to
16Mhz backplane signal format. the later step is not so easy in all
configuations of PDH signals insides DS3s.
Conclusion: In current design phase I use PMC_TEMUX + PMC_SPECTRA +
Micro (FLASH+RAM+MICROPROCESSOR+HDLC CONTROLLER)! Embedding temux and
micro section in FPGA will be for next version.
Hope this gives a clear perspective of my views, If not please let me
know.
Best Regards.
Masoud Naderi

Andrew Paule <lsboogy@qwest.net> wrote in message news:<Wt2Ua.177$TT2.87277@news.uswest.net>...
> Hi Masoud -
> 
> this should in theory be pretty easy, but you need to quantify many 
> things befor the decision is made  -  16MHz may be pretty slow, but is 
> there a channel to channel synch requirement - crosstalk - jitter - 
> others?  Decision should have more data for a basis than is here ( I 
> would guess that there is).  I could easily put enough nitrous into my 
> car so that the motor was capable of taking it into the 8's in a quarter 
> mile,  but the tranny certainly would not take it, and I'd probably 
> twist the crank if nothing else.
> 
> Andrew
> 
> Masoud Naderi wrote:
> 
> >Hi all,
> >I want to use PMC-Sierra chipset for my STM-1 card. Input to this card
> >is 16x16Mhz sync channels that comes from backplane. I can use
> >PMC_TEMUX chip(pm8316) to make 3xDS3 PDH channel and feed them to
> >PMC_SPECTRA chip (PM5342). But it seems using PMC_TEMUX chip is not
> >cost saving and not suitable for this design, because TEMUX can do
> >many things that wont use in this application. I think making DS3
> >signals from backplane signals (16Mhz) can be done easely in FPGA, so
> >bypassing TEMUX chip. It should be noted that single or multi E1
> >channels should be extraced from our output STM-1 signal (for example
> >from an ADM in SDH ring).
> >Please help me in this regard.
> >Regards.
> >M. Naderi
> >  
> >

Article: 58549
Subject: Re: Multi Pass Place & Route
From: Steve Lass <lass@xilinx.com>
Date: Fri, 25 Jul 2003 15:54:44 -0600
Links: << >>  << T >>  << A >>
Martin Euredjian wrote:

>Vikram Pasham <Vikram.Pasham@xilinx.com> wrote: 
>
>  
>
>>MPPR is used when PAR fails to meet timing constraints by a small margin with
>>the default cost table. Each cost table would serve as a seed for PAR algorithm
>>and result in a different placement and routing. One of these results may meet
>>your timing constraints, otherwise MPPR will indicate the best placement and
>>routing it achieved with the given cost tables.
>>
>>In your case all these MPPR results meet your timing constraints, as the timing
>>score is zero. Timing score is simply a summation in picoseconds of all timing
>>violations. You can use any of these cost table as long as your timing
>>constraints are met by PAR. The following solution record explains on how to
>>interpret MPPR report
>>    
>>
>
>Thanks for your post.  This much I knew, for it is available
>information in the documentation.
>
>My question had to do with the procedure to follow after running MPPR.
> Somewhere I saw a blurb about going back to P&R and running it in
>"Re-entrant" mode.
>
This would be for the case where none of the cost tables met your timing 
constraint.  You would
take the one with the lowest timing score and run re-entrant route on 
that ncd.

>  But, I couldn't find what this really means and
>how it uses the results of MPPR.  It seems to me that the easiest
>procedure is to simply re-run P&R with the best seed table (per the
>MPPR report).
>
There is no reason to rerun PAR becaue you already have the NCDs.  If 
the timing score is 0,
the only way to tell which one is best is with the design score.  The 
design score was created
about 12 years ago for the XC3000 family and although it might be some 
indication of which
table is best, it probably will not match the criteria you might say is 
best for your design.

In addition, just because one table is the best for your current design 
does not mean it would
be the best if you made a minor change to your design.

>  Is that pretty much the extent fo the relationship
>between MPPR and P&R?
>
The relationship is that if you run MPPR on 3 cost tables, then ran PAR 
on table 1, then 2, then 3,
you would have the same results.

The way you use it is for cases when your design does not route or does 
not meet timing running
PAR.  The, you would run MPPR to see if it can meet timing running 
multiple cost tables.  If it
doesn't, but gets close, then you take the best one and run re-entrant 
route.

Steve

>
>Thanks again,
>
>-Martin
>(posting from hotmail 'cause sbc/pacbell usenet servers seem to be in
>dire need of maintenance or exorcism)
>  
>




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