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
2019JanFebMar2019

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 124200

Article: 124200
Subject: Re: Is post-place and route simulation useful?
From: =?iso-8859-1?B?R2FMYUt0SWtVc5k=?= <taileb.mehdi@gmail.com>
Date: Fri, 14 Sep 2007 11:50:08 -0000
Links: << >>  << T >>  << A >>
On Sep 14, 2:54 pm, KJ <Kevin.Jenni...@Unisys.com> wrote:
> On Sep 14, 3:57 am, GaLaKtIkUs=99 <taileb.me...@gmail.com> wrote:> Hi,
> > Is the post place&route simulation so important?
> > IMHO doing post synthesis (or post translate) simulation for verifying
> > behavior than doing a post place and route static timing analysis is
> > sufficient and less resource consuming than doing a timing simulation.
>
> Once one is sufficiently skilled I would agree....at least for FPGA
> designs.  For ASICs where the cost for fixing an error is much, much
> higher one might have a different opinion.
>
> > Moreover if errors are found during timing simulations (by errors I
> > mean X or false results) they are almost always (for my cases)
> > difficultly traceable.
>
> Which sounds like you're maybe not quite there on the 'sufficiently
> skilled' front since you still get 'X' or false results.  Definitely a
> pain in the rear to trace back to the root cause through the post-
> route sim I agree.
What I meant is that if I see X or errors in post place and route
simulation than fixing them is almost impossible in reasonable time
(for me). But if I do timing analysis and fix all errors than do
timing simulation than the timing is true.
So to reformulate clearly:
Is it sufficient yo do post-synthesis simulation (of course after
having validated the design by behavioral simulation) + static timing
simulation to guarantee working design? in other words is it possible
to skip timing simulation this way?


Article: 124201
Subject: Re: Xilinx ISP JTAG progaramming (XCF32P using GPIO from V4FX12)
From: "cpope" <cepope@nc.rr.com>
Date: Fri, 14 Sep 2007 08:10:10 -0400
Links: << >>  << T >>  << A >>

"Petter Gustad" <newsmailcomp6@gustad.com> wrote in message
news:87abrqb8b8.fsf@gustad.com...
> "cpope" <cepope@nc.rr.com> writes:
>
> > from. I am running Linux on the PPC inside the FX12 so I'm thinking
>
> How do you get the bitstream (xsvf or whatever) into the FX12?
>
> Petter
> -- 
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?

I'm running a linux OS so I have several options: ftp, usb thumb drive, or
serial. I am worried about the size of the svf file as I only have about
32MB free space internal.

-Clark



Article: 124202
Subject: Re: Spartan-3E Slave Serial Configuration
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 14 Sep 2007 13:19:30 +0100
Links: << >>  << T >>  << A >>
"Andrew Greensted" <ajg112@ohm.york.ac.uk> wrote in message 
news:fcdo4g$au9$1@netty.york.ac.uk...
>
> Could someone just check the following for me:
>
> PROG_B driven by AVR needs to be 2.5V logic
> DIN driven by AVR 3.3V logic (I think)
> CCLK driven by AVR 3.3V logic
>
> INIT_B driven by FPGA 3.3V logic
> DONE driven by FPGA 2.5V logic
> DOUT driven by FPGA 3.3V logic
>
> Many thanks
> Andy

Hi Andy,
That's what I did on my last S3E design. I pulled PROG_B low through a 
schottky diode with a pullup to 2.5V at the FPGA.
All that said, I would rely on the datasheet more than usenet!
HTH, Syms. 



Article: 124203
Subject: Re: Xilinx ISP JTAG progaramming (XCF32P using GPIO from V4FX12)
From: neilla@pipstechnology.co.uk
Date: Fri, 14 Sep 2007 05:29:23 -0700
Links: << >>  << T >>  << A >>
On 14 Sep, 13:10, "cpope" <cep...@nc.rr.com> wrote:
> "Petter Gustad" <newsmailco...@gustad.com> wrote in message
>
> news:87abrqb8b8.fsf@gustad.com...
>
> > "cpope" <cep...@nc.rr.com> writes:
>
> > > from. I am running Linux on the PPC inside the FX12 so I'm thinking
>
> > How do you get the bitstream (xsvf or whatever) into the FX12?
>
> > Petter
> > --
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> > A: Top-posting.
> > Q: What is the most annoying thing on usenet and in e-mail?
>
> I'm running a linux OS so I have several options: ftp, usb thumb drive, or
> serial. I am worried about the size of the svf file as I only have about
> 32MB free space internal.
>
> -Clark

There is one nice advantage of using the jdrive for the XCFxxP
devices, and that is the erase time.  For the XSVF/SVF player there is
a fixed erase time of 140 seconds, which is the maximum time it can
take to erase an XCF32P.  The jdrive software can sit in a loop
polling a bit to see when the erase really completes, if you look in
the IEE1532 BSDL file for the XCFxxP device you will see what I mean.
There is also a similar issue with the programming time, but since
that is a much shorter delay you don't notice it quite so much.

Neill.


Article: 124204
Subject: Re: Spartan-3E Slave Serial Configuration
From: Andrew Greensted <ajg112@ohm.york.ac.uk>
Date: Fri, 14 Sep 2007 13:33:08 +0100
Links: << >>  << T >>  << A >>
Symon wrote:
  > Hi Andy,
> That's what I did on my last S3E design. I pulled PROG_B low through a 
> schottky diode with a pullup to 2.5V at the FPGA.
> All that said, I would rely on the datasheet more than usenet!
> HTH, Syms. 

Cheers Symon,
My plan was to use one of those tiny-logic single gates, they've got 5V 
tolerant inputs and can be by 2.5V. That should do the level conversion 
nicely.
Andy

-- 
Dr. Andrew Greensted      Department of Electronics
Bio-Inspired Engineering  University of York, YO10 5DD, UK

Tel: +44(0)1904 432828    Mailto: ajg112@ohm.york.ac.uk
Fax: +44(0)1904 432335    Web: http://www.bioinspired.com/users/ajg112

Article: 124205
Subject: Re: Is post-place and route simulation useful?
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Fri, 14 Sep 2007 16:03:32 +0300
Links: << >>  << T >>  << A >>
GaLaKtIkUsā„¢ wrote:
> Is the post place&route simulation so important?
> IMHO doing post synthesis (or post translate) simulation for verifying
> behavior than doing a post place and route static timing analysis is
> sufficient and less resource consuming than doing a timing simulation.

I'd say that both simulations are usually not necessary with FPGAs. RTL
simulations and STA analysis should be enough almost all the time.
Netlist simulations verify the synthesizer and timing constraints.
Formal equivalence checking might be faster way to verify RTL->netlist
synthesis results. And usually for FPGA the timing constraints are
not as complicated as with ASIC (no need for the process variation
analysis etc.)

> Moreover if errors are found during timing simulations (by errors I
> mean X or false results) they are almost always (for my cases)
> difficultly traceable.

That is the problem with netlists. I have spent weeks wondering what
happens inside ASIC netlists, where the X propagates and how
to fix them. NRE for ASIC is so high that netlist simulations
are important, but just for timing constraint verification, and
to catch stupid errors that are related to IO and test structures
that are inserted in by automatic tools.


--Kim

Article: 124206
Subject: Re: Xilinx ISP JTAG progaramming (XCF32P using GPIO from V4FX12)
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 14 Sep 2007 15:33:03 +0200
Links: << >>  << T >>  << A >>
"cpope" <cepope@nc.rr.com> writes:

> I'm running a linux OS so I have several options: ftp, usb thumb
> drive, or serial. I am worried about the size of the svf file as I
> only have about 32MB free space internal.

Then you could program on the fly as you transfer the data using any
of the above methods. 

Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 124207
Subject: Re: Open-Source VHDL Synthesis for FPSLIC?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 14 Sep 2007 07:52:21 -0700
Links: << >>  << T >>  << A >>
LowSNR wrote:

> I've been doing some development work over the past year or so on the
> Atmel FPSLIC platform.  I've run out of time on the license for the
> Mentor software that came with the dev kit ...

The choices I see are change platforms or buy a license.

       -- Mike Treseler

Article: 124208
Subject: Re: Is post-place and route simulation useful?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 14 Sep 2007 08:14:41 -0700
Links: << >>  << T >>  << A >>
GaLaKtIkUs wrote:

> Is the post place&route simulation so important?

Not so much for synchronous designs on FPGAs.

> ... doing post synthesis (or post translate) simulation for verifying
> behavior ...

A gate level sim tells me nothing
about behavior that I didn't learn from my code sim.
It may be a valid check-off item at release time
for the reasons that Kim mentioned.

..  then doing a post place and route static timing analysis

This is essential.

> ... less resource consuming than doing a timing simulation.

and STA finds all timing problems, where
a timing sim is lucky to find any.

> Moreover if errors are found during timing simulations (by errors I
> mean X or false results) they are almost always (for my cases)
> difficultly traceable.

Yes, and the root cause is almost always
the testbench or a vendor sim model,

 -- Mike Treseler

Article: 124209
Subject: Re: Is post-place and route simulation useful?
From: Andy <jonesandy@comcast.net>
Date: Fri, 14 Sep 2007 08:19:05 -0700
Links: << >>  << T >>  << A >>
Kim makes an excellent point: timing constraints are the biggest
reason for an experienced designer to run (or not run) post-route
timing simulations.  While most clock and IO constraints are pretty
straight forward and seldom cause a problem, false-path and multi-
cycle constraints are easily specified erroneously, and lacking
specialized formal tools to check/generate them, the only way to
verify them is with post-route timing simulations.

For that reason, If I don't need a multicycle or false path
constraint, I don't use it. I will put in a significant level of extra
work in the implementation to avoid them if necessary, and thus avoid
the need for post-route simulations.

That said, novice designers should run post-synthesis or post-route
simulations just to make sure they're not doing something stupid in
their synthesizable code.

By focusing on much faster RTL simulations (especially if you use
integers, variables, and only clocked processes wherever possible),
more "corner cases" can be covered in less time.

This should be obvious, but Static Timing Analysis is mandatory,
regardless of whether you run a full timing simulation.

Also, this holds for FPGA development where the cost of failure is
usually rather low, compared to ASICs. That said, there are some
rather expensive OTP FPGAs that would fall more under the ASIC
verification model, where full timing simulations are justified by the
NRE to fix a problem during hardware test/integration.

You have to ask yourself what kind of problems you are trying to
detect/prevent: design specification problems, verification problems,
tool problems (simulation, synthesis, P&R, STA, etc.), and what are
their relative probabilities as well as cost of detection vs cost of
repair?

Andy


Article: 124210
Subject: Re: Physical Design Contribution to FPGA/CPLD success
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 14 Sep 2007 08:29:33 -0700
Links: << >>  << T >>  << A >>
acd wrote:

> Would FPGAs have been successfull, if they had been implemented with
> vanilla CMOS gates and latches?

They wouldn't have been programmable.

     -- Mike Treseler

Article: 124211
Subject: Re: Physical Design Contribution to FPGA/CPLD success
From: Peter Alfke <alfke@sbcglobal.net>
Date: Fri, 14 Sep 2007 08:46:14 -0700
Links: << >>  << T >>  << A >>
Originally, FPGA had to overcome the "to small, too slow, too
expensive" criticism, and had to use every possible circuit trick to
become more efficient.
Replacing ASICs came later, when size, speed and cost had become
competitive with some ASIC applications.
If we had not pulled all the stops to become efficient, we might now
be a footnote in history,,,
Horribile dictu.
Peter Alfke


On Sep 14, 8:29 am, Mike Treseler <mike_trese...@comcast.net> wrote:
> acd wrote:
> > Would FPGAs have been successfull, if they had been implemented with
> > vanilla CMOS gates and latches?
>
> They wouldn't have been programmable.
>
>      -- Mike Treseler



Article: 124212
Subject: Re: Physical Design Contribution to FPGA/CPLD success
From: acd <acd4usenet@lycos.de>
Date: Fri, 14 Sep 2007 09:14:14 -0700
Links: << >>  << T >>  << A >>
On 14 Sep., 17:29, Mike Treseler <mike_trese...@comcast.net> wrote:
> acd wrote:
> > Would FPGAs have been successfull, if they had been implemented with
> > vanilla CMOS gates and latches?
>
> They wouldn't have been programmable.
>
>      -- Mike Treseler


Meant also to Peter:

Mike, either I did miss your irony or you did get me wrong:
Of course one could implement an FPGA  with vanilla CMOS
latches and gates, build your configuration registers with standard
latches,
build the LUT-readout multiplexer with standard gates,
build the routing with combinational multiplexers and standard
latches.
I guess, the Algotronix (later Xilinx 6200) devices would have been
more friendly for this, than the Xilinx 2000 devices,
but it could be done. You would just need way more transistors.

My assumption was that if Xilinx/AMD/Lattice & Co. would have done it
this way,  the capacity/cost would have been so poor that the FPGA
business had  never taken off, or at least much weaker and later.
Peter kind of confirmed that assumption, thanks.

Andreas


Article: 124213
Subject: Re: Xilinx ISP JTAG progaramming (XCF32P using GPIO from V4FX12)
From: "cpope" <cepope@nc.rr.com>
Date: Fri, 14 Sep 2007 12:21:12 -0400
Links: << >>  << T >>  << A >>

<neilla@pipstechnology.co.uk> wrote in message
news:1189772963.643390.40040@22g2000hsm.googlegroups.com...
> On 14 Sep, 13:10, "cpope" <cep...@nc.rr.com> wrote:
> > "Petter Gustad" <newsmailco...@gustad.com> wrote in message
> >
> > news:87abrqb8b8.fsf@gustad.com...
> >
> > > "cpope" <cep...@nc.rr.com> writes:
> >
> > > > from. I am running Linux on the PPC inside the FX12 so I'm thinking
> >
> > > How do you get the bitstream (xsvf or whatever) into the FX12?
> >
> > > Petter
> > > --
> > > A: Because it messes up the order in which people normally read text.
> > > Q: Why is top-posting such a bad thing?
> > > A: Top-posting.
> > > Q: What is the most annoying thing on usenet and in e-mail?
> >
> > I'm running a linux OS so I have several options: ftp, usb thumb drive,
or
> > serial. I am worried about the size of the svf file as I only have about
> > 32MB free space internal.
> >
> > -Clark
>
> There is one nice advantage of using the jdrive for the XCFxxP
> devices, and that is the erase time.  For the XSVF/SVF player there is
> a fixed erase time of 140 seconds, which is the maximum time it can
> take to erase an XCF32P.  The jdrive software can sit in a loop
> polling a bit to see when the erase really completes, if you look in
> the IEE1532 BSDL file for the XCFxxP device you will see what I mean.
> There is also a similar issue with the programming time, but since
> that is a much shorter delay you don't notice it quite so much.
>
> Neill.
>

Has anyone looked at xapp975 from xilinx? This is a lightweight version of
the programming which claims to not have the erase problem you cite.

Would be perfect for my application except:
1. the xcf32p has to be on its own jtag chain - how many times would you
have that in a design?
2. the byte interface is not very friendly - would work better if they made
it an OPB peripheral
3. revisioning is not supported

I'm still going to pursue it as I expect all of these issues could be
resolved, it's just that the first version of this came out last month.

-Clark



Article: 124214
Subject: Re: Physical Design Contribution to FPGA/CPLD success
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 14 Sep 2007 10:21:15 -0700
Links: << >>  << T >>  << A >>
acd wrote:

> Mike, either I did miss your irony or you did get me wrong:

Neither, although I suppose that everything
I say and do is ironic at some level.

The expensive part of an ASIC isn't the
gates and flops, it's the wires.
The big idea that eventually made FPGAs successfully
is programmable wires. Wherever I am on the chip
I can pick up a low skew clock with no effort
on my part. That's the special sauce.

              -- Mike Treseler

Article: 124215
Subject: post translate and post PAR problems with XST and Modelsim
From: alleynb@gmail.com
Date: Fri, 14 Sep 2007 10:56:38 -0700
Links: << >>  << T >>  << A >>
I am trying to do a Virtex4 design, I have completed the post
synthesis (XST) simulations in Modelsim - everything appears fine.
When I run the PAR and simulate the generated model. I get all zeros
on the output. None of the registers in the desing appear to be
loading. I have specified the timing constraints for the period of the
clock (only that constraint). Is there something I may be forgetting
to do? My desing is runnig at 125Mhz.

Thanks


Article: 124216
Subject: Re: Physical Design Contribution to FPGA/CPLD success
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 14 Sep 2007 11:05:01 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> The big idea that eventually made FPGAs successfully
                                          successful


Next big idea: A smart spell checker.

Article: 124217
Subject: Re: Spartan-3E Slave Serial Configuration
From: Brian Davis <brimdavis@aol.com>
Date: Fri, 14 Sep 2007 11:27:21 -0700
Links: << >>  << T >>  << A >>
Andrew Greensted wrote:
>
> Could someone just check the following for me:
>
> PROG_B  driven by AVR   needs to be 2.5V logic
> DIN     driven by AVR   3.3V logic (I think)
> CCLK    driven by AVR   3.3V logic
>
> INIT_B  driven by FPGA  3.3V logic
> DONE    driven by FPGA  2.5V logic
> DOUT    driven by FPGA  3.3V logic
>

Have a look at pages 101-121 of:
 http://www.xilinx.com/products/spartan3e/sp3e_power.pdf

This info may have all percolated into the datasheet by now,
but that's still a most useful document.

Brian


Article: 124218
Subject: add_file -verilog +define ..... filename.v
From: Abhi <walke.abhijeet@gmail.com>
Date: Fri, 14 Sep 2007 18:37:35 -0000
Links: << >>  << T >>  << A >>
Hi,
I have a question on Synplicity synthesis / FPGA synthesis.

Is there a way to give in the `defines from the command lines in
synplicity synthesis ..
something like

add_file -verilog +define ..... filename.v

I am not sure if it's +define or something else, so thought of giving
this querty to the group.
I have researched this stuff in the user and reference manual but
couldn't find a link.

Any kinda help is appreciated.

Thanks!


Article: 124219
Subject: Re: MicroBlaze Tutorial
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 14 Sep 2007 12:00:18 -0700
Links: << >>  << T >>  << A >>
That's a nice walkthrough but doesn't address the issue
of incorporating hardware designs.

> http://www.itee.uq.edu.au/~wu/downloads/uClinux_ready_Microblaze_design.pdf




Article: 124220
Subject: Re: Physical Design Contribution to FPGA/CPLD success
From: Andy <jonesandy@comcast.net>
Date: Fri, 14 Sep 2007 12:52:44 -0700
Links: << >>  << T >>  << A >>
On Sep 14, 3:59 am, acd <acd4use...@lycos.de> wrote:
> CPLDs and FPGAs both make (or made) use of "non-standard"
> implementation
> of digital circuits, namely wired-OR and pass-transistors.
> Both techniques are much more difficult to use in standard cell ASICs
> or gate arrays.
> Therefore, one could argue  that the use of these methods reduced the
> area and speed
> overhead induced by the programmability.
> So while many ASICs that have been replaced by FPGAs  would not have
> used the methods,
> the CPLDs/FPGAs did.
>
> How strong do you think was and is this effect?
> Would FPGAs have been successfull, if they had been implemented with
> vanilla CMOS
> gates and latches?
> Or better, how much smaller  the success story of FPGAs  would have
> been
> without the use of  pass transistors in LUTs and routing?
>
> Andreas

I think you're confusing the product of an ASIC and an FPGA. ASICs are
limited to "standard" cell devices, because the tools have to be
easily applicable (and verifiable!) to a wide variety of situations.

An FPGA (the virgin part, not the programmed application) is more like
a high-end processor, with much larger volumes to support dedicated
designs using "non-standard" features. I'm sure you'd find similar
tricks in any large, high-volume, fully custom, digital IC.

No major processor would survive in the market without similar tricks
either.

Andy


Article: 124221
Subject: Re: Open-Source VHDL Synthesis for FPSLIC?
From: Eric Smith <eric@brouhaha.com>
Date: Fri, 14 Sep 2007 13:55:58 -0700
Links: << >>  << T >>  << A >>
jkrauss@lowsnr.com wrote:
> I've been doing some development work over the past year or so on the
> Atmel FPSLIC platform.  I've run out of time on the license for the
> Mentor software that came with the dev kit,

If the dev kit is less expensive than the Mentor license, you could
buy another dev kit.

Article: 124222
Subject: Re: Is post-place and route simulation useful?
From: "HT-Lab" <hans64@ht-lab.com>
Date: Fri, 14 Sep 2007 21:12:28 GMT
Links: << >>  << T >>  << A >>

"Andy" <jonesandy@comcast.net> wrote in message 
news:1189783145.694707.69630@o80g2000hse.googlegroups.com...
> Kim makes an excellent point: timing constraints are the biggest
> reason for an experienced designer to run (or not run) post-route
> timing simulations.  While most clock and IO constraints are pretty
> straight forward and seldom cause a problem, false-path and multi-
> cycle constraints are easily specified erroneously, and lacking
> specialized formal tools to check/generate them, the only way to
> verify them is with post-route timing simulations.

Focus from Fishtail will find most MCP and FP's in your design and generate 
a bunch of PSL/SVA assertions to verify them. Assertions are great for 
validating MCP/FP's. If you are a burn and go kind of engineer than you can 
use Temento's Dialite to convert your MCP/FP assertions into hardware 
monitors and check that during hardware testing none of them triggers.

>
> For that reason, If I don't need a multicycle or false path
> constraint, I don't use it.
> I will put in a significant level of extra
> work in the implementation to avoid them if necessary, and thus avoid
> the need for post-route simulations.
>
> That said, novice designers should run post-synthesis or post-route
> simulations just to make sure they're not doing something stupid in
> their synthesizable code.

I would also add that gatelevel (structural) can be useful if your design is 
not working on "the board" (STA is all happy) since the whole chain from RTL 
to bitstream is not flawless and bad logic can be introduced during any of 
the intermediate stages. I know that gatelevel simulation is dead slow 
especially if you are using Vital but sometimes you need to run a gatelevel 
simulation to answer the above question.

>
> By focusing on much faster RTL simulations (especially if you use
> integers, variables, and only clocked processes wherever possible),
> more "corner cases" can be covered in less time.
>
> This should be obvious, but Static Timing Analysis is mandatory,
> regardless of whether you run a full timing simulation.
>
> Also, this holds for FPGA development where the cost of failure is
> usually rather low, compared to ASICs. That said, there are some
> rather expensive OTP FPGAs that would fall more under the ASIC
> verification model, where full timing simulations are justified by the
> NRE to fix a problem during hardware test/integration.

That reminds me of my first Radition Tolerant 1020 from Actel, at £1000 a 
pop (10 years ago) ...... those were the days of real FPGA's :-)

>
> You have to ask yourself what kind of problems you are trying to
> detect/prevent: design specification problems, verification problems,
> tool problems (simulation, synthesis, P&R, STA, etc.), and what are
> their relative probabilities as well as cost of detection vs cost of
> repair?

Good point!

Hans
www.ht-lab.com


>
> Andy
> 



Article: 124223
Subject: Re: Uses of Gray code in digital design
From: "KJ" <kkjennings@sbcglobal.net>
Date: Fri, 14 Sep 2007 21:20:57 GMT
Links: << >>  << T >>  << A >>

"Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote in 
message news:5kuvpsF5kqemU1@mid.individual.net...
>> I'm assuming from all this, that we're talking about interfacing to
>> async memory.  If so, then what you suggest will possibly fail timing
>> because of a race condition between the write strobe going inactive
>> and the address starting to change.  So just exactly when would you be
>> strobing the write signal itself?
>
> You wouldn't, if you'd read the thread you'd have seen that the write
> strobe is being held active and the (grey coded) address change is being
> used to action the write....
>
I read the thread but admit I did forgot the point about always writing to 
the SRAM.  For 'every clock cycle' read/write to SRAMs applications, I like 
the following

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=6&f=G&l=50&co1=AND&d=PTXT&s1=Jennings.INNM.&s2=Unisys.ASNM.&OS=IN/Jennings+AND+AN/Unisys&RS=IN/Jennings+AND+AN/Unisys

>
> I've never tried this in anger because no sram data sheet that I could
> find had any information on whether this mechanism would work, it was
> just an idea on how to stream data into an external SRAM faster.
>
Agreed, you'd probably have to get some more info from the SRAM suppliers to 
see if it would really work.

KJ



Article: 124224
Subject: Re: Physical Design Contribution to FPGA/CPLD success
From: Alex Colvin <alexc@TheWorld.com>
Date: Fri, 14 Sep 2007 21:34:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
>Originally, FPGA had to overcome the "to small, too slow, too
>expensive" criticism, and had to use every possible circuit trick to
>become more efficient.
>Replacing ASICs came later, when size, speed and cost had become
>competitive with some ASIC applications.
>If we had not pulled all the stops to become efficient, we might now
>be a footnote in history,,,
>Horribile dictu.
>Peter Alfke

Similar to Fortran, which was competing with hand-coded assembler and had 
to produce really good code. 
-- 
	mac the naļf



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
2019JanFebMar2019

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