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 110150

Article: 110150
Subject: Re: FPGA to SRAM port interface
From: "oen_br" <oen_no_spam@yahoo.com.br>
Date: 11 Oct 2006 10:59:36 -0700
Links: << >>  << T >>  << A >>
         _   _   _   _   _   _   _   _   _   _   _   _   _   _   _   _
PCLK  |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |
         _______
ALE   __/       \______________________________________________________
      __________________         ___         ___         ___         __
WRITE#                  \_______/   \_______/   \_______/   \_______/

             _______  __________  __________  __________  __________
DTADD ______/ ADDR  \/  DATA0   \/  DATA1   \/  DATA2   \/  DATA3   \__
            \_______/\__________/\__________/\__________/\__________/


Mike,

PCLK is 175MHz (DSP internal peripheral clock).
I can generate a 175MHz clock, but it will probably not be in phase
with PCLK.
As you can see, WRITE# signal is low for just one clock. If I have the
bad luck of sampling it at the transition points it is possible that
I'll miss the low part of it.
A 350MHz clock is too high! Maybe something a bit higher than 175.
If the "dangerous" aproach does not work, I'll try this one.

Luiz Carlos


Article: 110151
Subject: Re: Quartus II 6.0: System clock has been set back
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Wed, 11 Oct 2006 20:15:00 +0200
Links: << >>  << T >>  << A >>

> Also, when the Quartus web edition is "free," my license file is only
> good for 6 months and must renew it afterwards.  I guess Altera can
> pull the plug any time if they decide to do so.
>

While this is true, I do not think that this is some we have to be afraid 
of,
because the users have the option to "pull the plug", too.

Thomas 



Article: 110152
Subject: Re: free CAN field bus IP for EDK ?
From: rponsard@gmail.com
Date: 11 Oct 2006 11:32:54 -0700
Links: << >>  << T >>  << A >>
thanks Antti

LEON looks pretty interesting but it is too large to fit into xc3s500e
(starter kit)... as soon as the 1600 starter kit is available...

altium ? why not... an other tool

I will ask xilinx for an evaluation license... (all that is for edu.
and if we pay for software, we could no more pay for hardware...)


I am new to SoC, coming from software world... It seems to me that
these numerous buses (whisbone AHB simpcon EDK...) look like the .DLL
hell


Antti wrote:
> rponsard@gmail.com schrieb:
>
> > for those who have done it :
>
> no one around!
>
> > how much work is it to integrate a CAN controler as the one in opencore
> > into an =B5blaze-EDK design (day, week, month ???)
>
> choice 1:
>
> NO WORK, just take Altium Designer and use MicroBlaze or PPC with CAN,
> well it will be on wishbone as Altium designer uses MicroBlaze with wb
> wrapper
> its a bit cheating, AD uses MB from EDK, but it really isnt true EDK
> solution?
>
> choice 2:
> 1 day - integration
> 1+ month - testing and verification
>
> dumb estimates (your mileage may vary)
>
> choice 3:
> use GRLIB/LEON3 it already has OC CAN to AHB(APB?) wrapper
>=20
> Antti


Article: 110153
Subject: Re: 75Mhz Spartan3e microblaze
From: "Antti" <Antti.Lukats@xilant.com>
Date: 11 Oct 2006 11:49:12 -0700
Links: << >>  << T >>  << A >>
John Adair schrieb:

> One of the problems with OPB is that the more peripherals you add the
> slower it goes. All of the control signals data returns from modules
> etc are ORed together. There are ways to improve module response to
> clock e.g. pipelining the return of data. It is worth looked at the
> results in timing analyser to identify problem modules and see if you
> can do anything to improve the speed of them.
>
> On the brute force approach try using multiple place and route. Option
> can be set in the Placement options in ISE. Also playing with
> synthesiser switches - especially hierarchy settings may also help.
>
> John Adair
> Enterpoint Ltd.
>

John,
the OP was already doing multi-pass optimization with the xplorer
script
and he has pretty much minimal bare bones system so he should be
able to meet 65MHz+ timing

well there is almost another option

ethernet lite requires only 50mhz clock frequency - unfortunatly
Petalogix has only released the binary demo with the ethernet lite
uclinux drivers (GPL licensed ASFAIK) so the only option currently
is really getting the system clock freq above 65 and use full
ethernet core

Antti


Article: 110154
Subject: Re: Release Status of Spartan3E
From: "u_stadler@yahoo.de" <u_stadler@yahoo.de>
Date: 11 Oct 2006 12:02:07 -0700
Links: << >>  << T >>  << A >>
hi


i got a couple 500e pq208 from them.


MICRO COMPONENTS GMBH
LACKNERGASSE 32
A - 1170 WIEN
 
ING. ERNST RUTH
TEL.: +43 1 4789154 41
FAX : +43 1 4789154 43


urban


Article: 110155
Subject: Re: nicer code => slower code??
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Wed, 11 Oct 2006 14:31:25 -0500
Links: << >>  << T >>  << A >>
I had the same thing happen to me using ISE to synthesize a arithmatic unit. 
I can guarantee that no real changes were made, I just merged two modules 
into one and it was faster (didn't look at the size).


---Matthew Hicks


<burn.sir@gmail.com> wrote in message 
news:1160071377.108163.26640@m73g2000cwd.googlegroups.com...
>
> I was playing with this old design the other day and decided to
> "clean it up" a little bit (it was kinda messy). I moved some
> logic to their own modules for better readability. I also grouped
> some signals into VHDL records (don't know what its called, but
> if you ever browsed the LEON code, you know what i mean).
>
>
> I didn't change the functionality of the design (I did ran a
> large number of tests to be sure, of course). Furthermore, the changes
> were very isolated (only two files affected in a relatively large
> design)
>
> I was kind of surprised to see that after synthesis and PAR,
> I got a design that was:
>
> 1. 10% slower
> 2. marginally larger (few hundred LUTs)
>
> (yes, with same tool, same speed grade and so on)
>
>
> Has anyone seen this kind of behaviour before?
> Would this go away if I somehow "flattened" my design?
>
>
>
>
> bruns
> 



Article: 110156
Subject: Functional Languages in Hardware
From: "shidan" <shidan@gmail.com>
Date: 11 Oct 2006 12:44:51 -0700
Links: << >>  << T >>  << A >>
Are there any functional languages  that can be compiled to hardware at
the same or greater level of abstraction than languages like Mitrion-C
and Handel-C. Is it all research or is there anything that is practical?


Article: 110157
Subject: Re: TIG Being Ignored?
From: "JustJohn" <john.l.smith@l-3com.com>
Date: 11 Oct 2006 12:50:56 -0700
Links: << >>  << T >>  << A >>


On Oct 11, 8:03 am, "Brandon Jasionowski" <killerhe...@gmail.com>
wrote:

> Why is ISE ignoring my constraint?

Your statement:

> The first two nets listed are assigned to a timing name belonging to
> paths that are asychronous to another clock.

may show a mis-understanding of how the TNM and TNM_NET constraints
form timing groups (not "timing names", the name is just a label to
refer to the group). Timing groups are composed of instances of FFs,
memories, and other synchronous devices, they are _not_ composed of
nets. TNM_NET fans _forward_ from the named net and collects any
devices whose inputs are reached either directly or combinatorically
from that net.

To get a clue what's happening, use Timing Analyzer to take a look at
the timing groups that are formed by your grouping constraints:

> NET "ctrl1_clr" TNM_NET =3D "TN_ctrl_clr";
> NET "ctrl2_clr" TNM_NET =3D "TN_ctrl_clr";
> NET "sync_drpp_clr_inst/sync_r2<0>" TNM_NET =3D "TN_sync_drpp_clr";
> NET "sync_drpp_clr_inst/sync_r2<1>" TNM_NET =3D "TN_sync_drpp_clr";

Look at the group "TN_ctrl_clr".
Does it contain "Source: ctrl2_ins/curr_st_FFd1 (FF)"?
Look at the group "TN_sync_drpp_clr".
Does it contain "Destination: sync_drpp_clr_inst/sync_r1_1 (FF)"?
(I'm guessing no on both...)

If the groups don't contain the source and destination devices for the
timing path you want to ignore, the TIG constraint is not applied (or
worse, applied to a different set of sources/destinations that you did
not intend).

Three possible suggestions are:
1) If you want to ignore _all_ cross clock domain timing, you easily do
that with a TIG applied from your CLK1 group to your CLK2 group:
NET "adc_clk_dcm_clk0" TNM_NET "TG_Clk1";
NET "adc_clk_dcm_clkfx" TNM_NET "TG_Clk2";
TIMESPEC "TS_Clk1_to_Clk2" =3D FROM "TG_Clk1" TO "TG_Clk2" TIG;
(or whatever names you want to use for your TIMEGROUPsand TIMESPEC.)
I don't particularly like this though, it may hinder Place/Route by
allowing domain crossing nets to be excessively long, thus getting in
the way of more critical nets. It may be nicer to simply use a small
but achievable value:
TIMESPEC "TS_Clk1_to_Clk2" =3D FROM "TG_Clk1" TO "TG_Clk2"  2 ns;
(or whatever value works for you).

2) Closer to what you seem to want to do, use TPTHRU:

NET "ctrl1_clr" TPTHRU=3D TH_clr;
NET "ctrl2_clr" TPTHRU=3D TH_clr;
and either:
TIMESPEC "TS_Thru_clr" =3D FROM "TG_Clk1" THRU "TH_clr" TO "TG_Clk2" TIG;
or possibly better for P/R:
TIMESPEC "TS_Thru_clr" =3D FROM "TG_Clk1" THRU "TH_clr" TO "TG_Clk2" 2
ns;

3) To pick out only the particular paths that you show failing, use the
instance grouping constraint:
INST "ctrl2_ins/curr_st_FFd1" TNM "TG_Src1";
INST "sync_drpp_clr_inst/sync_r1_1" TNM "TG_Dst1";
TIMESPEC "TS_Src1_to_Dst1" =3D FROM "TG_Src1" TO "TG_Dst1"  TIG;
or
TIMESPEC "TS_Src1_to_Dst1" =3D FROM "TG_Src1" TO "TG_Dst1"  2 ns;

Hope one of these is of some help.
Regards,
John

> I've been performing post-map static timing analysis and have noticed
> that my TIG UCF constraint is being ignored for some reason. Here is
> what I have:
>
> <SNIP>
> ## TIG
> NET "ctrl1_clr" TNM_NET =3D "TN_ctrl_clr";
> NET "ctrl2_clr" TNM_NET =3D "TN_ctrl_clr";
> NET "sync_drpp_clr_inst/sync_r2<0>" TNM_NET =3D "TN_sync_drpp_clr";
> NET "sync_drpp_clr_inst/sync_r2<1>" TNM_NET =3D "TN_sync_drpp_clr";
> TIMESPEC "TS_TIG_clr2synch" =3D FROM "TN_ctrl_clr" TO "TN_sync_drpp_clr"
> TIG;
> </SNIP>
>
> The first two nets listed are assigned to a timing name belonging to
> paths that are asychronous to another clock. This clock drives
> registered ports of an instance (synchronization circuit) with port
> name sync_r2(1:0). Normally I would edit the UCF manually, but it
> absorbed some of the signal names, so instead I used the constraint
> tool to generate the above.
>
> When I run timing I get the following:
> <SNIP>
> WARNING:Timing:3223 - Timing constraint PATH "TS_TIG_clr2synch_path"
> TIG;
>    ignored during timing analysis.
> </SNIP>
>
> Here is one of the timing errors from the post-map static timing
> analyzer:
> <SNIP>
> Timing constraint: TS_adc_clk_dcm_clkfx =3D PERIOD TIMEGRP
> "adc_clk_dcm_clkfx" TS_adc_clk / 0.7
>         HIGH 50%;
>
>  278920 items analyzed, 4 timing errors detected. (4 setup errors, 0
> hold errors)
>  Minimum period is   8.415ns.
> -------------------------------------------------------------------------=
--=AD-----
> Slack:                  -0.270ns (requirement - (data path - clock path
> skew + uncertainty))
>   Source:               ctrl2_ins/curr_st_FFd1 (FF)
>   Destination:          sync_drpp_clr_inst/sync_r1_1 (FF)
>   Requirement:          0.571ns
>   Data Path Delay:      0.590ns (Levels of Logic =3D 1)
>   Clock Path Skew:      0.000ns
>   Source Clock:         adc_clk_dcm_clk0_bufg rising at 28.000ns
>   Destination Clock:    adc_clk_dcm_clkfx_bufg rising at 28.571ns
>   Clock Uncertainty:    0.251ns
>   Timing Improvement Wizard
>   Data Path: ctrl2_ins/curr_st_FFd1 to sync_drpp_clr_inst/sync_r1_1
>     Delay type         Delay(ns)  Logical Resource(s)
>     ----------------------------  -------------------
>     Tcko                  0.291   ctrl2_ins/curr_st_FFd1
>     net (fanout=3D22)    e  0.100   ctrl2_ins/curr_st_FFd1
>     Tfck                  0.199   ctrl2_ins/curr_st_Out11
>                                   sync_drpp_clr_inst/sync_r1_1
>     ----------------------------  ---------------------------
>     Total                 0.590ns (0.490ns logic, 0.100ns route)
>                                   (83.1% logic, 16.9% route)
>
> </SNIP>
>
> Why is ISE ignoring my constraint? How am I supposed to know what my
> true worst path is if I can't eliminate this timing error?
>=20
> Thanks,
> -Brandon


Article: 110158
Subject: spartan 3E starter kit and JOP
From: rponsard@gmail.com
Date: 11 Oct 2006 13:16:50 -0700
Links: << >>  << T >>  << A >>
does anyone port JOP (www.jopdesign.com) to the spartan 3E starter kit
(xc3s500e) ?

there is an implementation for the spartan 3 starter kit (xc3s200), but
if the work is already done for the new one, I will apreciate...


Article: 110159
Subject: Re: TIG Being Ignored?
From: "ajpanicker" <rekcinapja@gmail.com>
Date: 11 Oct 2006 13:18:43 -0700
Links: << >>  << T >>  << A >>
I completely agree with John. The groups that you have created might
not have a valid connection at all to ignore. The Instance based
grouping of the elements(third option) looks like the preferred
solution for you to dig out the actual critical paths..Please refer to
the constraints guide from the ISE --documents--software manuals(pdf)
for the correct syntax and to understand the grouping of elements and
create constraints,to inform the tool about such exceptions(path
specific).


Article: 110160
Subject: Re: nicer code => slower code??
From: "Andy" <jonesandy@comcast.net>
Date: 11 Oct 2006 13:47:50 -0700
Links: << >>  << T >>  << A >>
Most synthesis tools will not share resources across module boundaries,
other than really trivial identical registers, etc.

Splitting it up into more modules may have defeated some sharing going
on.

Andy


Matthew Hicks wrote:
> I had the same thing happen to me using ISE to synthesize a arithmatic unit.
> I can guarantee that no real changes were made, I just merged two modules
> into one and it was faster (didn't look at the size).
>
>
> ---Matthew Hicks
>
>
> <burn.sir@gmail.com> wrote in message
> news:1160071377.108163.26640@m73g2000cwd.googlegroups.com...
> >
> > I was playing with this old design the other day and decided to
> > "clean it up" a little bit (it was kinda messy). I moved some
> > logic to their own modules for better readability. I also grouped
> > some signals into VHDL records (don't know what its called, but
> > if you ever browsed the LEON code, you know what i mean).
> >
> >
> > I didn't change the functionality of the design (I did ran a
> > large number of tests to be sure, of course). Furthermore, the changes
> > were very isolated (only two files affected in a relatively large
> > design)
> >
> > I was kind of surprised to see that after synthesis and PAR,
> > I got a design that was:
> >
> > 1. 10% slower
> > 2. marginally larger (few hundred LUTs)
> >
> > (yes, with same tool, same speed grade and so on)
> >
> >
> > Has anyone seen this kind of behaviour before?
> > Would this go away if I somehow "flattened" my design?
> >
> >
> >
> >
> > bruns
> >


Article: 110161
Subject: Re: longest webcase record -- perhaps it is explained?
From: "colin" <colin_toogood@yahoo.com>
Date: 11 Oct 2006 13:49:23 -0700
Links: << >>  << T >>  << A >>
Austin

All I need is someone at Xilinx to tell me where the scan cells are in
the IOB. I'm fairly certain that they are in a simillar place to where
ALTERA clearly document them otherwise it would slow down the pin. I'm
almost certain that the pin will be SSTL for JTAG if I make it SSTL
functionally.

Your asking me to cripple a design functionally for the sake of the
right person at XILINX answering the question.
If I make the whole design CMOS then I can use a MAX II which I can
power from 2.5v without needing a vreg to 1.8.

Regards, in total exasperation

Colin

Austin Lesea wrote:
> Colin,
>
> Do not use any termination.
>
> If you use any termination at all, it will not work.
>
> That simple.
>
> If you don't use any termination, you may get reflections, and that
> might be a problem, too.
>
> Get Hyperlynx, and run the simulations yourself.
>
> Austin
>
> colin wrote:
> > Austin
> >
> > I'm fairly sure that you understand most/all of this but you have
> > suggested to the world that I don't......  :-)
> >
> > I am using a third party boundary scan tool from assett intertech which
> > uses the JTAG port to twiddle pins on certain devices and read back the
> > values on other pins on the same net so yes I'm fairly certain that I'm
> > using JTAG.
> >
> > If the coolrunner II is not programmed then there is no confusion, one
> > uses the bsdl file provided by xilinx which defines the jtag behaviour
> > of the device and the coolrunner will drive outputs and receive inputs
> > as CMOS to the value of whatever I have set VCCIO to for that bank.
> >
> > If the coolrunner has been programmed then there is a tool from xilins
> > called BSDLANNO which looks at the fitter output and the original bsdl
> > file and creates a new bsdl because inputs are input only for jtag, but
> > outputs can be IO still for JTAG.
> > your tech support took a week to tell me that outputs are output only
> > for jtag so 13 days ago
> > I showed them the bsdlanno documentation and they said they would get
> > back to me.
> >
> > There is no issue with SSTL receiving CMOS because CMOS drives rail to
> > rail (2.5v) which is what the SSTL driver does.
> > However a CMOS receiver threshold is somewhat different  to a SSTL rx
> > threshold which means there is not as much (I said it was a marketing
> > thing) noise immunity by the time the sstl signal has gone through the
> > sstl termination scheme.
> > My question is therefore what do I do to ensure that my boundary scan
> > gets done using sstl levels. Now waiting 3 weeks for this bit.
> >
> > Colin
> >
> >
> >
> > Austin Lesea wrote:
> >> So, you wish to drive a LVCMOS input from a SSTL output?
> >>
> >> If this is what you are doing, at 2.5 volts, then if the CPLD is
> >> programed for SSTL class I, and there are no resistors used (no
> >> terminations), then the SSTL output is compatible with the LVCMOS input.
> >>
> >> This can be simulated with any signal integrity simulation tool (like
> >> Mentor's Hyperlynx) in about 60 seconds (which I did).
> >>
> >> To really know, and to be absolutely sure, I would need the part number
> >> and manufacturer of the CPLD, and the IBIS file for the SSTL output (I
> >> used the SSTL_I output for a V4 FPGA).
> >>
> >> I think I understand the hotline's confusion now.  Your boundary scan
> >> has nothing to do with JTAG.  How confusing, as the only context that we
> >> have heard of boundary scan in, is JTAG.
> >>
> >> Austin
> >


Article: 110162
Subject: Re: Antifuse, lower cost?
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 12 Oct 2006 09:51:17 +1300
Links: << >>  << T >>  << A >>
rickman wrote:

> Jim Granville wrote:
> 
>>scott moore wrote:
>>
>>>I don't see testability as a barrier. Your yield is not dependent on the
>>>good or bad design of the customer (as it is in custom ICs), so the
>>>design as burned is testable. The design flow becomes more like an ASIC,
>>>with the customer providing bits and vectors. All the maker cares about
>>>is the go/no go for the device. It certainly argues for the maker
>>>getting more involved in the programming process, and judging from
>>>typical makers web sites, that is exactly what they do (Actel, etc.).
>>
>>Where that matters, is in the impacts of < 100% yield.
>>  You can't really mount the devices before programing, and so
>>suffer another handling step. Then you ideally need to
>>be able to decide which devices are duds _before_ you mount them
>>on your expensive PCB (that means costly vector testing), and
>>finally, who pays for the dud's ?
>>  I think only TI still makes OTP CPLDs (Atmel have a couple of MilSpec
>>ones alive )- everyone else has gone to EE, and that's on small/simple
>>devices.
>>  Looking at Actel's latest push, I see their FLASH devices are
>>pushed as low power (not their antifuse), and Actel claim the QuickLogic
>>PolarPro benchmark as the worst battery life of the low power alternatives.
>>http://www.actel.com/products/igloo/
>>
>>Pretty much places any OTP device in the NFND bucket ?
> 
> 
> I think you missed Scott's point.  He is saying that for a production
> of any volume, you can let the manufacturer program the devices.  They
> are better equipped and at that point it adds little to the price.
> Let's face it, the cost of testing any large FPGA is not trivial and
> the cost of factory programming antifuse parts is lost in the noise.
> In fact, once you let the factory program the parts, you can likely
> save on test costs since you only need to test the logic you are using,
> just like EasyPath, if I have the right name.  So factory programming
> will likely reduce the price of the antifuse parts over buying them
> yourself even without considering the cost of programming them in
> house.
<snip>

OK, but I don't see a lot of OTP vendor noise offering this.
Plus, a key AntiFuse pitch is security, and that paranoid user base is 
not likely to ship code out the door...

Also, if you shove programming 'out', how exactly do you develop/change 
the design ?
[maybe like another poster, who uses RAM fpgas to develop for OTP ones ? ]

-jg



Article: 110163
Subject: Re: longest webcase record -- understandably so
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 11 Oct 2006 14:45:44 -0700
Links: << >>  << T >>  << A >>
Colin,

Where are the scan cells?  What does that have to do with anything
whatsoever?

The scan cells are where they are convenient.  The scan chain is wired
to the JTAG controller, and the JTAG controller is wired to the JTAG pins.

Since I seem to be completely unable to help you, I apologize, as I
think I am answering your questions, only to have you be frustrated, and
ask me a seemingly completely unrelated new question.

Perhaps I should quit, right now, and trouble you no further,

Austin

Article: 110164
Subject: Re: Antifuse, lower cost?
From: "Peter Alfke" <peter@xilinx.com>
Date: 11 Oct 2006 14:53:46 -0700
Links: << >>  << T >>  << A >>
>From my (biased?) vantage point, I see antifuse parts being used only
in the niche markets where they offer an advantage that overcomes their
weakness:
Single-chip, instant-on, some level of security, and radiation-hardened
logic (flip-flops are a different matter).
Antifuse parts do not address the general market, as can be seen from
the sales and market-share numbers.
Peter Alfke, trying to be fair.
=================================
Jim Granville wrote:

>
> OK, but I don't see a lot of OTP vendor noise offering this.
> Plus, a key AntiFuse pitch is security, and that paranoid user base is
> not likely to ship code out the door...
>
> Also, if you shove programming 'out', how exactly do you develop/change
> the design ?
> [maybe like another poster, who uses RAM fpgas to develop for OTP ones ? ]
> 
> -jg


Article: 110165
Subject: Re: nicer code => slower code??
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Wed, 11 Oct 2006 16:57:18 -0500
Links: << >>  << T >>  << A >>
Thanks for the insight.  I thought that the synthesis engine would make a 
huge netlist/graph out of all of my modules and optimize from there ... but 
now that I think about it, ISE does report optimization of only single 
modules.


---Matthew Hicks


"Andy" <jonesandy@comcast.net> wrote in message 
news:1160599670.498873.57930@m7g2000cwm.googlegroups.com...
> Most synthesis tools will not share resources across module boundaries,
> other than really trivial identical registers, etc.
>
> Splitting it up into more modules may have defeated some sharing going
> on.
>
> Andy
>
>
> Matthew Hicks wrote:
>> I had the same thing happen to me using ISE to synthesize a arithmatic 
>> unit.
>> I can guarantee that no real changes were made, I just merged two modules
>> into one and it was faster (didn't look at the size).
>>
>>
>> ---Matthew Hicks
>>
>>
>> <burn.sir@gmail.com> wrote in message
>> news:1160071377.108163.26640@m73g2000cwd.googlegroups.com...
>> >
>> > I was playing with this old design the other day and decided to
>> > "clean it up" a little bit (it was kinda messy). I moved some
>> > logic to their own modules for better readability. I also grouped
>> > some signals into VHDL records (don't know what its called, but
>> > if you ever browsed the LEON code, you know what i mean).
>> >
>> >
>> > I didn't change the functionality of the design (I did ran a
>> > large number of tests to be sure, of course). Furthermore, the changes
>> > were very isolated (only two files affected in a relatively large
>> > design)
>> >
>> > I was kind of surprised to see that after synthesis and PAR,
>> > I got a design that was:
>> >
>> > 1. 10% slower
>> > 2. marginally larger (few hundred LUTs)
>> >
>> > (yes, with same tool, same speed grade and so on)
>> >
>> >
>> > Has anyone seen this kind of behaviour before?
>> > Would this go away if I somehow "flattened" my design?
>> >
>> >
>> >
>> >
>> > bruns
>> >
> 



Article: 110166
Subject: Re: Quartus II 6.0: System clock has been set back
From: "radarman" <jshamlet@gmail.com>
Date: 11 Oct 2006 15:14:42 -0700
Links: << >>  << T >>  << A >>
KJ wrote:
> radarman wrote:
> > KJ wrote:
> > >
> > > Maybe because there are companies like Synplicity and Mentor Graphics that
> > > sell tools that are not vendor specific and do not sell parts.  When
> > > Microsoft bundles things in and 'gives things away' people rant about how
> > > they drive the independent software vendors out of business....a similar
> > > argument would likely apply here.
> > >
> > > Altera, Xilinx, Synplicity, Mentor Graphics et al pay out hard cash to
> > > provide software tools and all expect some return on that investment in some
> > > form (either directly from the tool or indirectly through parts or both).
> > > If one (or more) of the parts guys gives the tools away it can probably be
> > > construed by the legal eagles in Washington as a tactic to drive a
> > > competitor out of business thus deserving of some close and unprofitable
> > > scrutiny.  Obviously they can get away with giving limited versions of the
> > > tool away; I'm sure Synp and Ment would prefer to make money off of those as
> > > well but apparently the perceived loss in revenue is not considered to be
> > > worth trying to recoup via the legal system, anti-trust laws, that sort of
> > > approach.
> > >
> > > Just my speculation.
> > >
> >
> > No, I think Altera and Xilinx give away the low-end stuff so that
> > students and hobbiests will get exposure to their products. After all,
> > if the price of entry is > $3k, how many college's, much less students,
> > will be able to provide a reasonable number of seats to do FPGA
> > designs? Also, the best students are going to want to do some work at
> > home, and most are certainly NOT going to be able to afford the full
> > Quartus or ISE package. With both Xilinx and Altera giving away low-end
> > versions of the software, those students can now choose either, or
> > both, to try out at home. The cost of development boards becomes the
> > next issue. (Xilinx is still winning this one)
> >
> > Thus, the free software is almost a promotional expense for the FPGA
> > vendors. It gives people a taste of what's available, and (hopefully)
> > gives the users a good impression.
>
> I have no doubt that it's in Altera and Xilinx and all other FPGA/CPLD
> vendors to supply free design software as a mechanism to hook potential
> and future customers.  My point was that if you're Mentor Graphics or
> Synplicity your flagship product is now competing against the free
> stuff.  Giving stuff away for 'free' causes companies to wave the
> 'anti-trust' flag when they see their business going down the tubes or
> rally the 'anti-dumping' troops when it comes from a foreign owned
> company.  Their are of course other responses as well but if you're
> running the business you might want to limit your exposure to that sort
> of thing.
>
> For yet another reason for a nominal charge.....
>
> Obviously one business strategy for the Mentors and Synplicitys of the
> world to try to compete in that environment is to wangle their way in
> and make the FPGA/CPLD vendors pay a license in exchange they will
> supply the hobbled version of their software.....which is why
> practically every FPGA vendor has some 'free' form of Modelsim for
> anyone who wants it basically.
>
> Now if the license fee that say Altera (or whoever) pays to Mentor
> Graphics is based on the number of Modelsim seats that they give away
> then Altera has an economic incentive to keep track of just how many of
> these 'freebies' they've given away.  Charging even a nominal fee to
> get that license is generally enough to thwart the spam attacks that
> might otherwise cause them to pony up a big chunk of cash to pay for
> all those freebies that were simply someone hatching an e-assault on
> them.  The FPGA vendors that choose to not charge even a nominal fee
> are potentially opening themselves up to a big cash payout if the fee
> they must pay is tied to how many seats they give away and someone
> decides to hit them up with a cyber attack.
>
> I'm not saying what they're doing is right, wrong or indifferent or
> that I even have a clue about how the agreements between the companies
> are worded just that I see a very plausible reason for some modest
> amount money to change hands, not as a profit making measure (since it
> isn't) or for future business (which it might), or for goodwill (which
> it is) but simply to limit their exposure to a license fee.
>
> KJ

I don't think a fee would work well, because they are very likely not
only treating the eval/hobby licenses as a promotional item, but
fighting software piracy as well. Remember, the "free" stuff is very
limited - really only good for hobby and student work. These seats
would probably have gone to pirated software, were it not for the free
licenses. Seriously, how many students or hobbyists are going to be
able to cough up $2.5k/year for a Quartus subscription? If they do,
would they have any money left over for devices or boards?

By giving away the limited licenses, they remove (most of) the desire
to pirate the software, while simultaneously getting positive exposure,
feedback, and useful marketing information from the users. By requiring
talkback for advanced features, they even get a free beta test dept as
well. Lastly, as an added bonus, those users who choose to develop with
Altera or Xilinx at home will likely suggest using their favorite
device at work. So, what would have likely been a loss becomes a
potential gain. Believe me, they make a buck off of those free
licenses.

It's a win for the users as well. Rather than going through the hassle
of finding a pirated copy, figuring out how to hack it, and then
getting no support on a very complex product, end users get the real
(if limited) deal and access to limited technical support.

I can definitely say for myself that I appreciate the freebie licenses,
as I fall into the category of people who couldn't otherwise afford to
do serious FPGA work at home.

Now, the Modelsim situation is a bit different. There could potentially
be other EDA companies that would look askance at Xilinx and Altera
giving away free Modelsim software, instead of their EDA software -
especially since Mentor Graphics is the 800 lb gorilla / Microsoft in
the EDA market. However, the "free" Modelsim software is virtually
useless for much more than homework problems. I'm actually a little
surprised at how many features, like code coverage, are excluded given
the product is virtually a live demo. I actually wouldn't be surprised
if the freebie Modelsim licenses get yanked because of a lawsuit from
another EDA tool vendor. This actually does smack of the kind of
illegal bundling that Microsoft has been accused of.

As for Synplicity, they don't compete with the free versions anyway. At
over $20k/seat, only serious users are going to be buying Synplify
licenses, and those are the folks who weren't satisfied with the
built-in synthesis tools already. It would be like Ferrari getting
upset that Ford is giving away Escorts.


Article: 110167
Subject: Re: Antifuse, lower cost?
From: "radarman" <jshamlet@gmail.com>
Date: 11 Oct 2006 15:37:09 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> Jim Granville wrote:
> > scott moore wrote:
> > >
> > > I don't see testability as a barrier. Your yield is not dependent on the
> > > good or bad design of the customer (as it is in custom ICs), so the
> > > design as burned is testable. The design flow becomes more like an ASIC,
> > > with the customer providing bits and vectors. All the maker cares about
> > > is the go/no go for the device. It certainly argues for the maker
> > > getting more involved in the programming process, and judging from
> > > typical makers web sites, that is exactly what they do (Actel, etc.).
> >
> > Where that matters, is in the impacts of < 100% yield.
> >   You can't really mount the devices before programing, and so
> > suffer another handling step. Then you ideally need to
> > be able to decide which devices are duds _before_ you mount them
> > on your expensive PCB (that means costly vector testing), and
> > finally, who pays for the dud's ?
> >   I think only TI still makes OTP CPLDs (Atmel have a couple of MilSpec
> > ones alive )- everyone else has gone to EE, and that's on small/simple
> > devices.
> >   Looking at Actel's latest push, I see their FLASH devices are
> > pushed as low power (not their antifuse), and Actel claim the QuickLogic
> > PolarPro benchmark as the worst battery life of the low power alternatives.
> > http://www.actel.com/products/igloo/
> >
> > Pretty much places any OTP device in the NFND bucket ?
>
> I think you missed Scott's point.  He is saying that for a production
> of any volume, you can let the manufacturer program the devices.  They
> are better equipped and at that point it adds little to the price.
> Let's face it, the cost of testing any large FPGA is not trivial and
> the cost of factory programming antifuse parts is lost in the noise.
> In fact, once you let the factory program the parts, you can likely
> save on test costs since you only need to test the logic you are using,
> just like EasyPath, if I have the right name.  So factory programming
> will likely reduce the price of the antifuse parts over buying them
> yourself even without considering the cost of programming them in
> house.
>
> If the programming were done with something other than electricity, the
> programming circuitry could be eliminated.  I seem to recall a company
> that used to provide fast ASIC-like prototypes with laser cutting of
> traces.  I have not heard much about them lately.  What was the down
> side of this approach?

I'm sure there are others, but I think you are referring to Altera's
"Hard Copy", which is technically a "structured ASIC". It's essentially
an ASIC comprised of a selection of pre-wired IP components from their
FPGA lines. (You get the same PLL/DLL's, M4K blocks, etc as a real
FPGA, but hard-wired together based on your netlist)

The advantage is that you get to develop your design in an FPGA, then
port to an ASIC  little or no modification to the original design. You
get a high level of confidence that if the design worked in the FPGA,
it will work in the ASIC, since the ASIC is essentially your FPGA
design with "hard" routing. The ASIC will even replace the FPGA on your
board without any modifications, since the pinout is identical save the
configuration pins. Lastly, you get an automatic speed boost (in some
cases, up to 100%).

The structured ASIC's do cost more than a true ASIC, so you have higher
recurring costs, but the initial investment is lower (by an order of
magnitude - $100k vs $1M), and you lose less of your NRE, since you
aren't reworking the design to operate in an standard ASIC flow. There
is also the lock-in problem as well. If the firm ever quit making the
parts, you are SOL, as they own most of the ASIC IP. You have to hope
that you pick the right structed ASIC firm, or do a lifetime buy at
some point. The only saving grace is that you still have the original
design files, and can begin migrating to another process while you sell
off your current inventory.

I haven't had a chance to use the process myself, since my employer can
afford to use FPGA's, or when the time arises, pony up for a true ASIC,
but it makes sense for middle tier players. You get most of the
advantages of an ASIC without the ridiculously expensive upfront costs.


Article: 110168
Subject: Re: EDK Bug
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 12 Oct 2006 08:55:24 +1000
Links: << >>  << T >>  << A >>
Hi Urban,

u_stadler@yahoo.de wrote:

> well that was a bit early.
> thanks again for the tip that solved the firs problem. but now i have
> another

If this is just the auto-generated Makefile created by EDK, then your best bet
is just to force EDk to re-write it.

From the Cygwin command line, in your project directory do

$ xps -nw system.xmp    (or whatever you XMP project file is called)
% save make
% exit

Then do

$ make -f system.make clean

to clean everything up before trying again.


If the design was created with an older version of EDK, xps will first run the
revup process.

Hope this helps,

John

Article: 110169
Subject: Re: longest webcase record -- understandably so
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 12 Oct 2006 11:58:47 +1300
Links: << >>  << T >>  << A >>
Austin Lesea wrote:

> Colin,
> 
> Where are the scan cells?  What does that have to do with anything
> whatsoever?
> 
> The scan cells are where they are convenient.  The scan chain is wired
> to the JTAG controller, and the JTAG controller is wired to the JTAG pins.
> 
> Since I seem to be completely unable to help you, I apologize, as I
> think I am answering your questions, only to have you be frustrated, and
> ask me a seemingly completely unrelated new question.
> 
> Perhaps I should quit, right now, and trouble you no further,

I think the OP is questioning how the device programming affects JTAG ?
He mentions before programming, and after programming.

If you are going to JTAG-scan a post-pgmd full system, I'd say it
helps to know which are IPs (to prevent accidental drive)
- I'm guessing that's what BSDLANNO does ?

My understanding of bondary scan is that once you are in that mode,
the config fuses actually don't care, and the system does not know if 
the device is new/blank/pgmd, so scan is the same in all cases.

I think Colin is trying to confirm that, but with modern devices with 
many IO options, it is not a silly question - and one could argue that
ideally, post pgm scan _should_ use the Pin-option information.
(but I don't think it does, on anyones CPLDs - correct me if I am wrong ? )

-jg



Article: 110170
Subject: Re: boundary scan
From: "Subroto Datta" <sdatta@altera.com>
Date: 11 Oct 2006 17:01:36 -0700
Links: << >>  << T >>  << A >>
Hello Frank,

Quartus II 6.0 has the new Virtual JTAG megafunction, sld_virtual_jtag,
with which you can gain access to the device JTAG interface and develop
your own IP to use the JTAG interface as a simple serial communication
channel.  A set of TCL commands in the jtag package available in the
quartus_stp.exe TCL shell provide you a way to communicate with the
device using any of the Altera programming hardware, such as
USBBlaster, or to figure out the low level JTAG scan sequence if you
need to control the JTAG using your own hardware.  Please read the user
guide at http://www.altera.com/literature/ug/ug_virtualjtag.pdf for
more detailed information.

Hope this helps,
Subroto Datta
Altera Corp.

On Oct 10, 4:59 am, Frank van Eijkelenburg <some...@work.com.invalid>
wrote:
> I know about the bscan blocks in the xilinx virtex devices (bscan_virtex4 for
> instance). With these blocks you can make your own interface by use of the
> boundary scan usercode instruction.
>
> Does something like this exists for altera devices?
> 
> TIA,
> Frank


Article: 110171
Subject: Re: FPGA and ZBT/NoBL SRAM timing issue
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Wed, 11 Oct 2006 17:25:18 -0700
Links: << >>  << T >>  << A >>

Yes. I see now. Thank you.

> Yes, but you made it complicated again be delaying
> the clock. The ZBT is designed to have a full clock
> cycle of setup. If anything you need to have a negative
> delay on the clock to avoid hold issues. But in principle
> the ZBT interface is design for SRAM an FPGA using the same
> undelayed clock.
>



Article: 110172
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 12 Oct 2006 10:39:05 +1000
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com wrote:

> That they block both 3rd parties and open source from having access to
> the FPGA internals and tools internals means their customers are
> limited to what tools their limited resource development teams can
> cobble togather.
> 
> With a more open disclosure, it would be interesting to see what both
> open source and for-profit 3rd parties could do to make a market out of
> providing high performance FPGA tools and integrated development
> systems with FPGA assisted routing.

To this day, I'm flabbergasted that silicon vendors actually charge
money for their tools!?! If you want to push your silicon, then wouldn't
giving away tools only serve to sell more devices???

I'm *sure* more than one decision on Altera vs Xilinx has been made
purely on the cost and strength (or otherwise) of the tools!?!

As for open-source, I'd love to see it myself, but it would be a
vendor's nightmare! "My design simulates fine but doesn't work in
silicon... I'm using the red-hat disto of Quartus II v7.4.5 patch level
12 with the turbo annealing enhancements v2.1b4. Oh, and I found a bug
so I patched the timing analyzer myself too..."

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

From john_mccluskey@hotmail.com Wed Oct 11 18:36:35 2006
Path: newsdbm04.news.prodigy.com!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!news.linkpendium.com!news.linkpendium.com!news.glorb.com!out02b.usenetserver.com!news.usenetserver.com!in01.usenetserver.com!news.usenetserver.com!wesley.videotron.net!weber.videotron.net.POSTED!not-for-mail
From: John McCluskey <john_mccluskey@hotmail.com>
Subject: Re: ISE/EDK computer selection
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Message-Id: <pan.2006.10.12.01.36.35.687521@hotmail.com>
Newsgroups: comp.arch.fpga
References: <1160399541.151483.7330@k70g2000cwa.googlegroups.com> <452d2e85$1@news.fhg.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Lines: 13
Date: Wed, 11 Oct 2006 21:36:35 -0400
NNTP-Posting-Host: 66.131.182.144
X-Complaints-To: abuse@videotron.ca
X-Trace: weber.videotron.net 1160616986 66.131.182.144 (Wed, 11 Oct 2006 21:36:26 EDT)
NNTP-Posting-Date: Wed, 11 Oct 2006 21:36:26 EDT
Xref: prodigy.net comp.arch.fpga:121112

On Wed, 11 Oct 2006 19:49:35 +0200, Michael Sch÷berl wrote:

>> I am buying a new for my work. I do a lot of synhesis, map and P&R
>> using ISE 8.2 (Windows) in Xilinx EDK with quite complex systems.
>> Building a HW for such a system can take a very long time, so selection
>> of an appropriate computer is a must.

get a big whack (4 Gbytes or more) of PC6400 ECC DDR2 memory.   ECC is
important, because without, you won't be able to detect memory errors,
which can cause weird PAR problems.

John


Article: 110173
Subject: Re: Xilinx MicroBlaze 4.00.a source codes released by Xilinx !?
From: "Uncle Noah" <nkavv@skiathos.physics.auth.gr>
Date: 11 Oct 2006 19:24:31 -0700
Links: << >>  << T >>  << A >>
Hi there

it seems now that there is another download as "xapp730.zip" at the
Xilinx website. Has anyone checked this out? (i'm on pstn so will check
it tomorrow from office).

so it was a leak :(


Article: 110174
Subject: Re: Altera Quartus II 5.1 SP2 fails on MIF/HEX reconfig
From: "Subroto Datta" <sdatta@altera.com>
Date: Thu, 12 Oct 2006 03:37:17 GMT
Links: << >>  << T >>  << A >>
Hi Radarman,

   This is probably a bug in Quartus II 5.1 SP1. If you have an support 
incident opened email me the number so that we can verify it with the 
design, or zip the project archive  and emailit to me separately. We can ley 
you know if this has been fixed in 6.0 or if it is still a problem fix it 
for 6.1.

Thanks,
Subroto Datta
Altera Corp.

"radarman" <jshamlet@gmail.com> wrote in message 
news:1160531029.492131.266030@m7g2000cwm.googlegroups.com...
>I posted a service request with Altera on this, but I thought I would
> see if anyone else has seen this problem.
>
> I have written a small 8-bit microcomputer system for my Altera DE2
> board. The system has  16kB ROM that I preinitialize with an intel .hex
> format file.
>
> The design takes quite a while to fit because I want to operate it at a
> relatively high clock rate (100MHz), so I turned on smart-compile. Now
> that the basic hardware is functioning, and I am only changing the ROM
> image, I would expect to simply recompile and let Quartus read in the
> new .hex file.
>
> However, when I try to recompile, I get an error:
> Internal Error: Sub-system: QATM, File: qatm_mif_update.cpp, Line: 554
> RAM/CAM MIF reconfig failed
> Quartus II Version 5.1 Build 216 03/06/2006 SJ Web Edition
> Service Pack Installed:  2
>
> Note, the fitter doesn't (seem) to have a problem reading the .hex
> file. I can manually rerun the fitter, and it appears to work just
> fine. I believe the fitter is working properly because the address
> patterns seems consistent with a hang - not an uninitialized memory.
>
> This is on a Windows XP workstation. The project files are mounted from
> a file server on drive Y:.
>
> Thanks!
> 





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