Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
On 4/28/2010 6:12 PM, Nico Coesel wrote: > Symon<symon_brewer@hotmail.com> wrote: >> way, they could stop ARM's technology from ending up in everyone else's >> computers and gadgets.” > > Apple buying ARM makes no sense at all. Why bother if you can get a > license for almost nothing. What Apple wants at this moment is to be > able to design their own SoCs for a tighter fit to their wishes in > order to reduce power consumption. > What part of "stop ARM's technology from ending up in everyone else's computers and gadgets.” would make no sense at all? And how do you know what makes sense for Apple? Have you been drinking German lager in Redwood City? Or are you on the Heinekin? Love, Syms.Article: 147501
On 4/28/2010 5:28 PM, Pete Fraser wrote: > "Symon"<symon_brewer@hotmail.com> wrote in message > news:hr9nai$9rp$1@news.eternal-september.org... > >> I wonder what will happen if Apple buy ARM? > > There would be an interesting symmetry to that. > IIRC the original ARM (by Acorn RISC Machines) > owed quite a bit of its architecture to the 6502 used > in the BBC micro (and also in early Apples). > > That's going back a bit. I remember the $zero page indirect addressing!Article: 147502
On Apr 28, 6:58=A0pm, Symon <symon_bre...@hotmail.com> wrote: > On 4/28/2010 6:11 PM, Muzaffer Kal wrote: > > > > > On Wed, 28 Apr 2010 17:21:33 +0100, Symon<symon_bre...@hotmail.com> > > wrote: > >> I wonder what will happen if Apple buy ARM? > > >>http://www.thisislondon.co.uk/standard-business/article-23826703-city..= . > > >> =93A deal would make a lot of sense for Apple,=94 said one trader. =93= That > >> way, they could stop ARM's technology from ending up in everyone else'= s > >> computers and gadgets.=94 > > > The agreements signed before the acquisition survive the acquisition > > and if the licensees had any legal sense, there would be a clause > > which states if the new owner couldn't support the licensees, they > > would get a full rights perpetual license (in case ARM went bankrupt > > and/or got acquired by someone who doesn't want to support the license > > business anymore) > > Wow, we have a lawyer posting. On CAF, no less. Can I claim my first > amendment rights if I use hyperbole on you? Or will you use Justice Eady > on me? Is the hyperbole the European version of the superbowl? I guess it has that funny round football in it. :-) Anyway, the company I work for went through something very similar with a DSP architecture; the licensor got out of that business, and the licensee (us) are able to continue selling it without support. How brain-dead would it be to go through all the cost of building a chip, that you then aren't allowed to make and sell simply because somebody bought a company you licensed some of the IP from? In any case, I have a different theory about Apple. The best kind of ARM license (which very few companies have) is an "architecture license" which allows you to implement the arm ISA how you see fit. (The standard ARM "implementation license" makes you take and use ARM's RTL. Your synthesizer can optimize the RTL, but you can't change it at all.) Architecture licenses are very expensive, and even they sometimes come loaded with restrictions. For example, a recent press release says "Infineon is an ARM partner that has an ARM architecture license specifically for security applications." Think about that -- they don't need to use ARM's RTL; but their result is limited in field of use. Other restrictions in the architecture license involve whether you can add additional instructions, etc. Marvell has an architecture license (via Intel via DEC) that was negotiated before ARM got wildly popular, so chances are it's pretty liberal. There are rumors that Apple has one as well, but maybe it has restrictions like the Infineon one. Certainly, if the rumors are correct it was negotiated within the last 3 years. I can well imagine Apple going to ARM to negotiate a more full- featured license, then ARM telling them how much it would cost, then Apple threatening to just buy them. So, maybe it's just a negotiating posture. But there are other reasons Apple might want ARM. These include things like getting all their designers -- not just hardware designers, but also groups like their compiler team. Apple would probably be happy to mate up ARM's compiler with LLVM. In short, it might just be a really good match at a lot of levels. Regards, PatArticle: 147503
On Thu, 29 Apr 2010 00:58:58 +0100, Symon <symon_brewer@hotmail.com> wrote: >On 4/28/2010 6:11 PM, Muzaffer Kal wrote: >> On Wed, 28 Apr 2010 17:21:33 +0100, Symon<symon_brewer@hotmail.com> >> wrote: >>> I wonder what will happen if Apple buy ARM? >>> >>> http://www.thisislondon.co.uk/standard-business/article-23826703-city-aflame-with-takeover-talk-of-arm-and-xstrata.do >>> >>> “A deal would make a lot of sense for Apple,” said one trader. “That >>> way, they could stop ARM's technology from ending up in everyone else's >>> computers and gadgets.” >> >> The agreements signed before the acquisition survive the acquisition >> and if the licensees had any legal sense, there would be a clause >> which states if the new owner couldn't support the licensees, they >> would get a full rights perpetual license (in case ARM went bankrupt >> and/or got acquired by someone who doesn't want to support the license >> business anymore) > >Wow, we have a lawyer posting. One doesn't have to be a lawyer to know what goes into these agreements. I have been involved in IP license deals (and specifically micro-processor IP license from an ARM competitor) and simply paid attention to what the agreements says. > Can I claim my first amendment rights if I use hyperbole on you? I think you're prone to it so be my guest. > Or will you use Justice Eady on me? ??? -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 147504
On 29.4.2010 1:25, whygee wrote: > Noone should let the marketing dept. create a product on a napkin, > Austin should ask the real engineers ;-) Fortunately the fpga vendors do not figure out themselves alone what would be the next nice fpga. They run long questionaries and discussions with engineers from big customers to define the future products. From that material they create some kind of compromise that suits most of the customers, and add their competitive twists to that. --KimArticle: 147505
On 28/04/2010 18:28, Pete Fraser wrote: > "Symon"<symon_brewer@hotmail.com> wrote in message > news:hr9nai$9rp$1@news.eternal-september.org... > >> I wonder what will happen if Apple buy ARM? > > There would be an interesting symmetry to that. > IIRC the original ARM (by Acorn RISC Machines) > owed quite a bit of its architecture to the 6502 used > in the BBC micro (and also in early Apples). > It didn't exactly owe any of its architecture to the 6502, but the ARM designers were extremely familiar with the 6502 and its pros and cons. The original ARM was very much a "start from scratch" design based on the most recent ideas in RISC development - in fact part of what made the ARM different was that they had no legacy compatibility requirements at all. It had to be fast enough to emulate a 6502 in software (so that existing BBC Micro software could run), but that made no impact on the hardware. About the only architectural overlap I can think of is that the 6502 made substantial use of pipelining, which was considered a "RISC" feature at the time it was designed, and was uncommon in such small CISC chips.Article: 147506
Hi,
I am starting a new project using Xilinx Virtex5. I will be using the
Aurora protocol for Rocket IO GTX interfaces. Plan is to use Xilinx
ISE10.1.
I am planning to use Xilinx's Aurora core from coregen. I will need to
design a bridge to communicate to the Aurora link interface.I am new to
using Aurora.
If any one has worked on the same can you please advise me of
1. any known problems with Aurora and ISE 10.1
2. things to remember while designing for Aurora interface
3. any other known issues.
Your reply is highly appreciated.
Regards
Binu
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 147507On Wed, 28 Apr 2010 16:55:13 -0700 (PDT), rickman <gnuarm@gmail.com> wrote: >That is one long reply... > >On Apr 28, 6:56 am, Brian Drummond <brian_drumm...@btconnect.com> >wrote: >> On Tue, 27 Apr 2010 15:56:57 -0700 (PDT), rickman <gnu...@gmail.com> wrote: >> > Or maybe I should say that I don't think describing >> >combinatorial logic outside of clocked processes is inherently less >> >desirable. >> Where there are combinatorial outputs to be described, I agree, I'll describe >> them outside the main process. > >No, I am talking about logic that drives the registers. For example, >I have a PLL circuit which has a few registers, but several adders and >a few shift operations (mult/div). I give each a separate concurrent >statement to facilitate debugging. I could put it all inside the >register process, but I can do things with signals I can't do with >variables, such as bring them to the outside world. I'm not saying a separate combi process is wrong; I just haven't found a need for it. Using signals for their different semantics - I am with you on that score.. However I use them in synchronous processes, alongside variables, and this departs from the "one process with variables" template. Perhaps this simplifies the remaining cases until a process is unnecessary. Two reasons I use signals in processes: (1) as you say, it sometimes gives easier debugging. I am using a simulator (ISIM) that doesn't yet display variables in the wave window. (2) Using signals for pipeline registers, I can describe a pipeline right way round! Using variables I would have to describe it backwards. Variables do keep the declarations local. However my next move will be to use blocks to keep the signal declarations local too. (I feel a need to carefully check the tool support for this!) I'm unclear why you say a separate concurrent statement facilitates debugging; are you stepping through code in the simulator? (I haven't done that in over ten years) >Maybe this is a reflection of how we think differently for both design >and debug. I am an old school hardware designer and I think in terms >of registers and logic blocks. So my design reflects that I guess. I suspect we both keep a TTL Databook on the shelf... >> I just use VHDL's conditional signal assignments for that purpose. As it's >> purely combinational, I have never found the need for an equivalent that I can >> use inside a process. > >Heck, that is very limited. You can't even use in inside of a >separate signal assignment. Try combining the conditional signal >assignment with anything else. I would like to be able to use it >inside the conditional for an if (sometimes) or combine it is ways >that allows the assignment to more directly state the logic of the >problem rather than my having to convert the logic to suit the flow of >the structure. Such as Bernd's mux-with-enable example yesterday. He used a process, and suggested the alternative in Verilog was a huge array of signals. One intermediate signal between mux and enable, and the VHDL solution is easily understood and less verbose. (Though a combi process would also work) And as Alan said, VHDL-2008 promises support for these (combi and select) in processes. >> If VHDL is to adopt a conditional operator I hope it can do better than that! >> Something less surprising, and generalisable to other discrete types or at least >> other enums. >> Channel_Gain <= Channel_Color ? 0.11 : 0.55 : 0.34; >> -- nice and compact, but descending order to remain compatible with Boolean >> --------------------------------- > >I think this is a rather trivial example. Why not use the selected >signal assignment? As you said above; because it isn't combinable - e.g. in a process - yet. >The mnemonic for a boolean conditional operator is pretty simple, it is >the same as an IF statement. But to extrapolate that to descending >order for other data types is a bit of a reach. A better solution all round would be to replace it with an if-expression (in which "if", "then", "else" are explicit, (don't rely on the reader knowing C) and a case-expression for the (n>2) enumeration and integer subrange cases. But that seems to have fallen out of favour since Algol-W. >> There would of course be an associative form of the expression >> Channel_Gain <= Channel_Color ? red =>0.34 : green =>0.55 : blue=>0.11; >> to make the bugs harder to bury. > >Isn't this just a selected signal assignment? Essentially yes - the difference (which, I confess I didn't know, had gone in VHDL-2008) being that you can use it in a process. I suppose I'm just saying I appreciate the VHDL-2008 changes which don't break the language, rather than adding ?: which would. >> It's precisely that wart-free-ness that lets you extend it (e.g. by adding >> functions) in simple ways that actually work, instead of frustrating you. > >I don't get why you think the conditional operator would be a wart. >It is just an operator. It is a trinary operator rather than uniary >or binary, but it is still an operator and would violate nothing about >VHDL. For a start, what would the syntax for overloading it look like? My guess is: horrible. And definitely not worth rewriting half the parser for one operator on one specific enumerated type. >I've been warned about verilog, mostly in this thread, and I've been >told once I try it I won't go back. We'll see later this summer... >maybe. I'd certainly be interested to know how you get on. My prejudices are my own; I'd rather spend the time learning how to push VHDL harder for more productivity. I have the feeling we've barely scratched the surface yet. - BrianArticle: 147508
Brian Drummond wrote:
> On Wed, 28 Apr 2010 16:55:13 -0700 (PDT), rickman <gnuarm@gmail.com> wrote:
>> The mnemonic for a boolean conditional operator is pretty simple, it is
>> the same as an IF statement. But to extrapolate that to descending
>> order for other data types is a bit of a reach.
>
> A better solution all round would be to replace it with an if-expression (in
> which "if", "then", "else" are explicit, (don't rely on the reader knowing C)
> and a case-expression for the (n>2) enumeration and integer subrange cases.
>
> But that seems to have fallen out of favour since Algol-W.
Conditional expressions in the "if-then-else" syntax are being proposed
for the next Ada standard, and are already implemented in the GNU Ada
compiler. See http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00327.html.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
Article: 147509d_s_klein <d_s_klein@yahoo.com> writes: > On Apr 11, 1:46Â am, Anssi Saari <a...@sci.fi> wrote: >> d_s_klein <d_s_kl...@yahoo.com> writes: >> > It's part of Altera's 'check for updates'. >> >> > Just install rpm and be done with it; that's what I did. >> >> Isn't it easier to just symlink rpm to /bin/true? > > That would depend on the return code the calling application (Quartus) > was expecting. > > Having 'rpm' loaded on a Linux system is not evil. For me it's causing more problems with it than without it since there are no rpm packages installed and I keep getting the message "error: cannot open Packages index using db3" which seem to confuse Quartus more than the "rpm: Command not found." message. > (Who is slightly annoyed by the OP's belligerent attitude and lack of > etiquette.) You mean that I did not respond to your "Top-posted only to annoy ;)" message? -- .sig removed by request.Article: 147510
Hendrik <hendrik.eeckhaut@gmail.com> writes:
> You misunderstood. The only absolute path is in the user interface. If
That's my point. You have to change a path or do some operation.
> you move your project, you will also have to change parameters to
> point Emacs to the new location, be it a command line parameter.
I don't change any location or parameters in emacs. I just open the
source file and the build will be relative to the source file itself.
Most of the time I have multiple emacs windows open. I don't close
them ("uptime" for emacs is typically several months). To build on a
different machine I simply switch to the other emacs window and type
C-c C-k to build.
This is just a minor distraction of Eclipse. The most annoying part
for me is to dig out -O flags etc. far down in the hierarchy of
windows and dialog boxes. In my makefile based setup I know exactly
where to find them.
Petter
--
.sig removed by request.
Article: 147511Symon <symon_brewer@hotmail.com> writes: > I wonder what will happen if Apple buy ARM? Didn't Apple buy ARM a long time ago? I seem to remember that Apple and VTI (VLSI Tools Inc) purchased a large share in Acorn many years ago. That's actually how ARM was created if memory serves me right. Petter -- .sig removed by request.Article: 147512
On Apr 29, 7:12=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Wed, 28 Apr 2010 16:55:13 -0700 (PDT), rickman <gnu...@gmail.com> wrot=
e:
> >That is one long reply...
>
> I'm unclear why you say a separate concurrent statement facilitates debug=
ging;
> are you stepping through code in the simulator? (I haven't done that in o=
ver ten
> years)
Not for stepping, although I sometimes do that. It is so I can put up
each result in the simulator...
DCO <=3D DCO + (Integrated / INTG_GAIN) + (ErrorReg * PROP_GAIN);
This is overflowing an intermediate result. How do you debug? In the
process of debugging I also found the intermediate results need
saturating arithmetic, at least in test. By using separate
assignments for each step I can see what each operator is doing and
why it is crapping out. Once I split it up, I am leaving it, although
I am removing the saturation logic.
> >I think this is a rather trivial example. =A0Why not use the selected
> >signal assignment? =A0
>
> As you said above; because it isn't combinable - e.g. in a process - yet.
I am refering to the situation where it is available. It may be in
VHDL 2008, but I guess my machine is still running in 2003.
> >The mnemonic for a boolean conditional operator is pretty simple, it is
> >the same as an IF statement. =A0But to extrapolate that to descending
> >order for other data types is a bit of a reach. =A0
>
> A better solution all round would be to replace it with an if-expression =
(in
> which "if", "then", "else" are explicit, (don't rely on the reader knowin=
g C)
> and a case-expression for the (n>2) enumeration and integer subrange case=
s.
>
> But that seems to have fallen out of favour since Algol-W.
I'm not sure what you are referring to. An if is a sequential control
flow structure. I guess you are saying to give it a dual use. The
boolean operator is in common usage and there is no good reason to not
include it in VHDL. I don't know what the syntax is, but I assume it
is similar or the same as in Verilog.
> >> There would of course be an associative form of the expression
> >> Channel_Gain <=3D Channel_Color ? red =3D>0.34 : green =3D>0.55 : blue=
=3D>0.11;
> >> to make the bugs harder to bury.
>
> >Isn't this just a selected signal assignment?
>
> Essentially yes - the difference (which, I confess I didn't know, had gon=
e in
> VHDL-2008) being that you can use it in a process.
In a process this is a case statement. The real difference is that
you can use it inside an assignment while the case statement or
selected signal assignment can't.
foo <=3D ralph + (('1' =3D Mode) ? A : B);
compared to
with Mode select
foo <=3D ralph + A when '1',
ralph + B when '0',
(others =3D> '-') when others;
Both can get very unreadable if they get more complex. However, there
have been many times I have had to write very messy code or at a
minimum had to think hard about how to make it clear using the current
constructs.
> I suppose I'm just saying I appreciate the VHDL-2008 changes which don't =
break
> the language, rather than adding ?: which would.
I don't get the "break" part. I think that is a subjective opinion.
> >I don't get why you think the conditional operator would be a wart.
> >It is just an operator. =A0It is a trinary operator rather than uniary
> >or binary, but it is still an operator and would violate nothing about
> >VHDL.
>
> For a start, what would the syntax for overloading it look like?
Why would it be any different from what we currently use??? What does
it look like?
> My guess is: horrible.
>
> And definitely not worth rewriting half the parser for one operator on on=
e
> specific enumerated type.
Ok, now you are going off to unsubstantiated claims. I doubt anyone
would agree to go with a feature that required rewriting half the
compiler.
> >I've been warned about verilog, mostly in this thread, and I've been
> >told once I try it I won't go back. =A0We'll see later this summer...
> >maybe.
>
> I'd certainly be interested to know how you get on.
>
> My prejudices are my own; I'd rather spend the time learning how to push =
VHDL
> harder for more productivity. I have the feeling we've barely scratched t=
he
> surface yet.
We'll see. First I have to finish my current project. I am at the
final few bugs and each one is a trip back and forth to the customer.
Rick
Article: 147513Hi, I' m new to FPGA and I want to design a board with a Xilinx Spartan6 FPGA and 4GB of RAM. Is it realistic to have a such quantity of RAM on a board? I suppose that there are design constraints to do it, is it easier to do it with DDR2 than DDR3 or others? The Spartan6 integrated memory controller only treats 16bits bus, I suppose I can' t use easily DIMM memory? How to proceed to do it the simplest possible? Any documents? Thank you for me clarify. christopheArticle: 147514
Symon <symon_brewer@hotmail.com> wrote: >On 4/28/2010 6:12 PM, Nico Coesel wrote: >> Symon<symon_brewer@hotmail.com> wrote: >>> way, they could stop ARM's technology from ending up in everyone else's >>> computers and gadgets.” >> >> Apple buying ARM makes no sense at all. Why bother if you can get a >> license for almost nothing. What Apple wants at this moment is to be >> able to design their own SoCs for a tighter fit to their wishes in >> order to reduce power consumption. >> > >What part of "stop ARM's technology from ending up in everyone else's >computers and gadgets.” would make no sense at all? Such a move would get immediate attention from many trade commitees. Possibly severe fines like Intel and Microsoft received from the EU to start with. >And how do you know what makes sense for Apple? Follow what Apple has been doing (they never bought the PowerPC architecture) and knowing how to build a competitive embedded platform. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 147515
Hi fellows,
I have been working on a Virtex5 LX110 design using VHDL and ISE
tools. My problem is that I cannot meet my timing constraints or the
desired clock frequency. When I look at the timing report, I realized
that the large delay is due to a signal with a large fanout. This has
caused the delay to be dominated by routing (82%). Here is the portion
of timing report:
Maximum Data Path: dut_inst/userlogic/CM1/d3_tem_0 to dut_inst/
userlogic/YC1/Y3_out_n_4
Location Delay type Delay(ns) Physical
Resource
Logical Resource(s)
-------------------------------------------------
-------------------
SLICE_X20Y56.DQ Tcko 0.471
dut_inst/userlogic/CM1/d3_tem<0>
dut_inst/userlogic/CM1/d3_tem_0 SLICE_X14Y142.AX net
(fanout=77) 6.659 dut_inst/userlogic/CM1/d3_tem<0>
SLICE_X14Y142.COUT Taxcy 0.439 dut_inst/
userlogic/YC1/Madd_Y3_n_0_addsub0000_cy
dut_inst/userlogic/YC1/Madd_Y3_n_0_addsub0000_cy
SLICE_X14Y143.CIN net (fanout=1) 0.000 dut_inst/
userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<3>
SLICE_X14Y143.COUT Tbyp 0.104 dut_inst/
userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<7>
dut_inst/userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<7>
SLICE_X14Y144.CIN net (fanout=1) 0.000 dut_inst/
userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<7>
SLICE_X14Y144.CMUX Tcinc 0.334 dut_inst/
userlogic/YC1/Y3_n_0_addsub0000<11>
dut_inst/userlogi/YC1/Madd_Y3_n_0_addsub0000_xor<11>
SLICE_X14Y149.B1 net (fanout=2) 1.078 dut_inst/userlogic/
YC1/Y3_n_0_addsub0000<10>
SLICE_X14Y149.BMUX Topbb 0.613 dut_inst/userlogic/
YC1/Y3_n_0_cmp_le0000
dut_inst/userlogi/YC1/Mcompar_Y3_n_0_cmp_le0000_lut<5>
dut_inst/userlogic/YC1/Mcompar_Y3_n_0_cmp_le0000_cy<5>
SLICE_X16Y146.A1 net (fanout=13) 1.106 dut_inst/userlogic/
YC1/Y3_n_0_cmp_le0000
SLICE_X16Y146.A Tilo 0.094 fifo_in_inst/
bram_fifo_36x512_gen.bram_fifo_36x512_inst/BU2/U0/grf.rf/gcx.clkx/
wr_pntr_gc_asreg<8>
dut_inst/userlogic/YC1/Y3_out_n_mux0002<4>_SW2 SLICE_X17Y147.A2
net (fanout=1) 0.867 N1189
SLICE_X17Y147.CLK Tas 0.026 dut_inst/
userlogic/YC1/Y3_out_n<7>
dut_inst/userlogic/YC1/Y3_out_n_mux0002<4>
dut_inst/userlogic/YC1/Y3_out_n_4
-------------------------------------------------
---------------------------
Total 11.791ns (2.081ns logic,
9.710ns route)
(17.6% logic,
82.4% route)
##########################################################################
The signal with the large fanout is the output of a flip-flop. The
Synthesizer, on the other hand, finds another critical path with much
less delay. So, I guess the timing error happens because the
synthesizer cannot detect/optimize this path. But I don't know how to
fix this problem. Do I need to change my VHDL code or use other
constraints in my project. I appreciate your help.
-ehsan
Article: 147516On Apr 28, 1:40=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote: > On 26/04/2010 23:09, Wastrel wrote: > > > > > > > On Apr 25, 11:54 pm, David Brown<da...@westcontrol.removethisbit.com> > > wrote: > >> On 23/04/2010 21:39, Rich Webb wrote: > > >>> On Fri, 23 Apr 2010 10:19:07 -0700 (PDT), Wastrel > >>> <stephensdigi...@gmail.com> =A0 =A0wrote: > > >>>> On Apr 21, 1:08 pm, Jon Beniston<j...@beniston.com> =A0 =A0wrote: > >>>>> It's running ok for me on Windows 7 64-bit. > > >>>>> What particular part of the software are you having problems with? > > >>>>> Jon > > >>>> Well it installs alright, but Altium Designer 6 can't find it - > >>>> whereas it did on my XP box. One problem is that Windows 7 likes to > >>>> put 32 bit legacy programs under Program FIles(x86), but Quartus won= 't > >>>> install there because it can't handle spaces or special characters i= n > >>>> it's filenames. > > >>> Tell it to use the 8.3 name for the directory (one way of seeing this= is > >>> to do a "dir /X" from a command prompt). For the directory above, the > >>> name would be "c:\progra~2\". > > >> Alternatively, avoid "Program Files" or "Program Files (x86)" like the > >> plague - these are seriously stupid path names MS has chosen. > > >> When installing almost any new software, you have a free choice of the > >> installation path - if you think you might ever want to refer to the > >> program or its files by path name (such as the command line), use > >> something like "c:\Progs\" as the base instead of "c:\Program Files". > > >> I have no idea whether this will help you here or not, but it will avo= id > >> the awkward installation path.- Hide quoted text - > > >> - Show quoted text - > > > Well Altium support got back to me and said basically the same thing > > you guys are: "It works OK for me" > > > They told me to verify that the system environment variable > > "QUARTUS_ROOTDIR" pointed to the right folder - it did. I upgraded the > > OS to Windows 7 Professional from "Home Premium" still no joy. When I > > run Windows' compatibility troubleshooter it comes back with > > "Incompatible Application" so there's something funky going on. I'm > > wasting way to much time on this stupid problem, but it's not so easy > > finding an XP box anymore so I'm not just sure what my next move is. > > I know you've already found the answer, but this is just for > completeness sake... > > There are some suppliers that still produce systems with XP installed - > Dell being perhaps the best known. =A0They refer to it as "Win 7 Pro > downgraded to XP", and charge extra for it. =A0I think of it as "Win 7 > /upgraded/ to XP", and think it is worth the money. =A0There are many > tools in the embedded development world that don't play well with > anything other than XP. =A0Win 7 64-bit works better than XP 64-bit, so i= f > you need more than 3.5 GB memory, Win 7 is a good choice. =A0But other > than that I have seen no reason to pick Win 7 over XP, and XP is always > faster on the same hardware. > > As has been suggested, an alternative is to use virtual machines. =A0I > recommend Virtual Box - it's perhaps not quite as integrated as the "XP > mode" of Win 7 Pro, but it is much more flexible. =A0It's also free and > cross-platform, and you can move the virtual machines between different > hosts.- Hide quoted text - > > - Show quoted text - I'll have to look into some of these virtual machines. I'm sure this won't be the only speedbump I hit doing embedded development under Win7. What kind of performance hit can I expect? In the old days I used to fool around with CPM 2.2/Z80 emulators under DOS and WINE under Linux and my impression then was " well isn't that cute", but never considered really working in that environment. I imagine they have come a ways since then. BobArticle: 147517
On Thu, 29 Apr 2010 09:09:54 -0700, Ehsan wrote: > Hi fellows, > > I have been working on a Virtex5 LX110 design using VHDL and ISE tools. > My problem is that I cannot meet my timing constraints or the desired > clock frequency. When I look at the timing report, I realized that the > large delay is due to a signal with a large fanout. This has caused the > delay to be dominated by routing (82%). Here is the portion of timing > report: > > Maximum Data Path: dut_inst/userlogic/CM1/d3_tem_0 to dut_inst/ > userlogic/YC1/Y3_out_n_4 > Location Delay type Delay(ns) Physical > Resource > > Logical Resource(s) > ------------------------------------------------- > ------------------- > SLICE_X20Y56.DQ Tcko 0.471 > dut_inst/userlogic/CM1/d3_tem<0> > > dut_inst/userlogic/CM1/d3_tem_0 SLICE_X14Y142.AX net (fanout=77) > 6.659 dut_inst/userlogic/CM1/d3_tem<0> SLICE_X14Y142.COUT > Taxcy 0.439 dut_inst/ > userlogic/YC1/Madd_Y3_n_0_addsub0000_cy > > dut_inst/userlogic/YC1/Madd_Y3_n_0_addsub0000_cy > SLICE_X14Y143.CIN net (fanout=1) 0.000 dut_inst/ > userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<3> > SLICE_X14Y143.COUT Tbyp 0.104 dut_inst/ > userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<7> > > dut_inst/userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<7> SLICE_X14Y144.CIN > net (fanout=1) 0.000 dut_inst/ > userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<7> SLICE_X14Y144.CMUX Tcinc > 0.334 dut_inst/ userlogic/YC1/Y3_n_0_addsub0000<11> > > dut_inst/userlogi/YC1/Madd_Y3_n_0_addsub0000_xor<11> SLICE_X14Y149.B1 > net (fanout=2) 1.078 dut_inst/userlogic/ > YC1/Y3_n_0_addsub0000<10> > SLICE_X14Y149.BMUX Topbb 0.613 dut_inst/userlogic/ > YC1/Y3_n_0_cmp_le0000 > > dut_inst/userlogi/YC1/Mcompar_Y3_n_0_cmp_le0000_lut<5> > > dut_inst/userlogic/YC1/Mcompar_Y3_n_0_cmp_le0000_cy<5> SLICE_X16Y146.A1 > net (fanout=13) 1.106 dut_inst/userlogic/ > YC1/Y3_n_0_cmp_le0000 > SLICE_X16Y146.A Tilo 0.094 fifo_in_inst/ > bram_fifo_36x512_gen.bram_fifo_36x512_inst/BU2/U0/grf.rf/gcx.clkx/ > wr_pntr_gc_asreg<8> > > dut_inst/userlogic/YC1/Y3_out_n_mux0002<4>_SW2 SLICE_X17Y147.A2 net > (fanout=1) 0.867 N1189 > SLICE_X17Y147.CLK Tas 0.026 dut_inst/ > userlogic/YC1/Y3_out_n<7> > > dut_inst/userlogic/YC1/Y3_out_n_mux0002<4> > > dut_inst/userlogic/YC1/Y3_out_n_4 > ------------------------------------------------- > --------------------------- > Total 11.791ns (2.081ns logic, > 9.710ns route) > (17.6% logic, > 82.4% route) > > ########################################################################## > > The signal with the large fanout is the output of a flip-flop. The > Synthesizer, on the other hand, finds another critical path with much > less delay. So, I guess the timing error happens because the synthesizer > cannot detect/optimize this path. But I don't know how to fix this > problem. Do I need to change my VHDL code or use other constraints in my > project. I appreciate your help. > > -ehsan You can set a general max_fanout limit in the XST script, -max_fanout 32 Or you can put a max_fan synthesis directive on the signal in your RTL code.Article: 147518
On Apr 29, 12:09=A0pm, Ehsan <ehsan.hosse...@gmail.com> wrote: > Hi fellows, > > I have been working on a Virtex5 LX110 design using VHDL and ISE > tools. My problem is that I cannot meet my timing constraints or the > desired clock frequency. When I look at the timing report, I realized > that the large delay is due to a signal with a large fanout. This has > caused the delay to be dominated by routing (82%). Here is the portion > of timing report: > > =A0Maximum Data Path: dut_inst/userlogic/CM1/d3_tem_0 to dut_inst/ > userlogic/YC1/Y3_out_n_4 > =A0 =A0 Location =A0 =A0 =A0 =A0 =A0 =A0 Delay type =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0Delay(ns) =A0Physical > Resource > > Logical Resource(s) > =A0 =A0 ------------------------------------------------- > ------------------- > SLICE_X20Y56.DQ =A0 =A0 =A0Tcko =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A00.471 > dut_inst/userlogic/CM1/d3_tem<0> > > dut_inst/userlogic/CM1/d3_tem_0 SLICE_X14Y142.AX =A0 =A0 net > (fanout=3D77) =A0 =A0 =A0 6.659 =A0 =A0 =A0 =A0 =A0 dut_inst/userlogic/CM= 1/d3_tem<0> > SLICE_X14Y142.COUT =A0 Taxcy =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.439 =A0 = =A0 =A0 =A0 =A0 dut_inst/ > userlogic/YC1/Madd_Y3_n_0_addsub0000_cy > > dut_inst/userlogic/YC1/Madd_Y3_n_0_addsub0000_cy > =A0SLICE_X14Y143.CIN =A0 =A0net (fanout=3D1) =A0 =A0 =A0 =A00.000 =A0 =A0= =A0dut_inst/ > userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<3> > =A0SLICE_X14Y143.COUT =A0 Tbyp =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00.104 = =A0 =A0 =A0dut_inst/ > userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<7> > > dut_inst/userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<7> > SLICE_X14Y144.CIN =A0 =A0net (fanout=3D1) =A0 =A0 =A0 =A00.000 =A0 =A0 du= t_inst/ > userlogic/YC1/Madd_Y3_n_0_addsub0000_cy<7> > SLICE_X14Y144.CMUX =A0 Tcinc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.334 =A0 = =A0 dut_inst/ > userlogic/YC1/Y3_n_0_addsub0000<11> > > dut_inst/userlogi/YC1/Madd_Y3_n_0_addsub0000_xor<11> > SLICE_X14Y149.B1 =A0 =A0 net (fanout=3D2) =A0 =A0 =A0 =A01.078 =A0 =A0dut= _inst/userlogic/ > YC1/Y3_n_0_addsub0000<10> > SLICE_X14Y149.BMUX =A0 Topbb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.613 =A0 du= t_inst/userlogic/ > YC1/Y3_n_0_cmp_le0000 > > dut_inst/userlogi/YC1/Mcompar_Y3_n_0_cmp_le0000_lut<5> > > dut_inst/userlogic/YC1/Mcompar_Y3_n_0_cmp_le0000_cy<5> > SLICE_X16Y146.A1 =A0 =A0 net (fanout=3D13) =A0 =A0 =A0 1.106 =A0 dut_inst= /userlogic/ > YC1/Y3_n_0_cmp_le0000 > SLICE_X16Y146.A =A0 =A0 =A0Tilo =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00.094 = =A0 =A0 =A0 =A0 =A0fifo_in_inst/ > bram_fifo_36x512_gen.bram_fifo_36x512_inst/BU2/U0/grf.rf/gcx.clkx/ > wr_pntr_gc_asreg<8> > > dut_inst/userlogic/YC1/Y3_out_n_mux0002<4>_SW2 SLICE_X17Y147.A2 > net (fanout=3D1) =A0 =A0 =A0 =A00.867 =A0 N1189 > SLICE_X17Y147.CLK =A0 =A0Tas =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.026 = =A0 =A0 dut_inst/ > userlogic/YC1/Y3_out_n<7> > > dut_inst/userlogic/YC1/Y3_out_n_mux0002<4> > > dut_inst/userlogic/YC1/Y3_out_n_4 > =A0 =A0 ------------------------------------------------- > --------------------------- > =A0 =A0 Total =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 11.791ns (2.081ns logic, > 9.710ns route) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(17.6% logic, > 82.4% route) > > #########################################################################= # > > The signal with the large fanout is the output of a flip-flop. The > Synthesizer, on the other hand, finds another critical path with much > less delay. So, I guess the timing error happens because the > synthesizer cannot detect/optimize this path. But I don't know how to > fix this problem. Do I need to change my VHDL code or use other > constraints in my project. I appreciate your help. > > -ehsan I think your problem has little or nothing to do with fanout, the high fanout net just happens to be the one that's hard to meet timing on, 6.6ns is a very long net. Usually this is due to something along the lines of different destinations on the fanout being spread around the chip. Thus if timing is met on to one destination, it will fail to destinations on the other side of the chip; generally a tough situation for the router. So the problem is routing, forget the fanout. Focus on trying to area group the logic that's on that fanout into a tighter area. Alternatively, if you can tolerate the latency and if it's easy to put in, you can add a register on that path (retiming in synthesis can more or less do this too). ChrisArticle: 147519
austin <austin@xilinx.com> wrote: >Nico, > >How many will you buy? How many will everyone buy? > >Putting anything in an FPGA device has to be backed by 1+ billion ($) >in 2+ years for the family ... or I can't even afford to get a water >glass at the table in the marketing restaurant. > >Mask sets at 22nm, and development costs, are completely out of this >world. We may be making a FPGA device that can be programmed to do >what you want, but we still have to serve the broadest market >possible, so we can afford to do it at all, and still make a profit >(reasonable ROI). > >Imagine putting something in the FPGA device, and getting it >wrong...it could damage the company so severely that we could lose out >on one, or more technology cycles to our competition. Are you sure about that? While Microsoft and Sony where fighting to get on the edge of technology regarding game consoles Nintendo came up with the Wii. Inferior when it comes to performance but superior when it comes to its controls and ease of use. Now imagine a 32 and/or 64 pin QFN device with an ARM core, a 50k Spartan 3 like FPGA fabric some ram and some flash. Price around $3 in large quantities and available from every street corner (Digikey, Farnell, RS-components, etc). Such a device would open a whole new world. One could make a microcontroller with high speed / custom pheripherals. This would probably take extra knowledge from a microcontroller manufacturer. Or create a 2-die device and hook the FPGA fabric to an external memory bus. AFAIK the Spartan 3AN series uses 2 dies in one package. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 147520
On Thu, 29 Apr 2010 09:09:54 -0700 (PDT), Ehsan <ehsan.hosseini@gmail.com> wrote: >Hi fellows, > >I have been working on a Virtex5 LX110 design using VHDL and ISE >tools. My problem is that I cannot meet my timing constraints or the >desired clock frequency. When I look at the timing report, I realized >that the large delay is due to a signal with a large fanout. This has >caused the delay to be dominated by routing (82%). Here is the portion >of timing report: >SLICE_X20Y56.DQ Tcko 0.471 >(fanout=77) 6.659 dut_inst/userlogic/CM1/d3_tem<0> >SLICE_X14Y142.COUT Taxcy 0.439 dut_inst/ 77 is not a particularly large fanout, but 6.6ns is a very long time in a V5. This looks like a pathologically bad placement between source (X20Y56) and destination (X14Y142). Three approaches: (1) run MAP and PAR again with a different seed ( set the -t option to 2, 3, 4 etc) until you find a setting that passes timing. Note that MAP and PAR now both need the -t flag, and both need the same value for it. This requires no real thought, only CPU time, so is often an easy way to make the problem go away until you change the design and MAP comes up with another pathological placement (then you change the seed again) (2) Using FPGA Editor, move the offending component (the source in this case, since the destination appears to be a carry chain) closer to the destination, then run a re-entrant routing pass from the command line to improve timings. (ISE10 has a silly bug preventing reentrant routing from the GUI) (3) Change the design somehow; setting the "max fanout" limit as the General suggests, will force synthesis to use two or more copies of the signal source. This will reduce the fanout but more importantly, it gives MAP a chance to place one copy closer to the destination, to reduce the routing length. - BrianArticle: 147521
On 21 Apr, 21:03, Wastrel <stephensdigi...@gmail.com> wrote: > My XP box died the other day and was replaced by a 64 bit Windows7 > machine. Now my $%^&Quartus II software won't run, and Altera says > Win7 ain't supported. Anybody know of a workaround? I'm developing on > the Altera Cyclone III FPGA on the Altium Designer NanoBoard 3000. > > Thx, > > Bob It works OK for me on my laptop with Win7 x64. I have it installed in the default c:\Altera directory. LeonArticle: 147522
On Thu, 29 Apr 2010 05:42:47 -0700 (PDT), rickman <gnuarm@gmail.com> wrote:
>On Apr 29, 7:12 am, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:
>> On Wed, 28 Apr 2010 16:55:13 -0700 (PDT), rickman <gnu...@gmail.com> wrote:
>> >That is one long reply...
>>
>> I'm unclear why you say a separate concurrent statement facilitates debugging;
>> are you stepping through code in the simulator? (I haven't done that in over ten
>> years)
>
>Not for stepping, although I sometimes do that. It is so I can put up
>each result in the simulator...
>
>DCO <= DCO + (Integrated / INTG_GAIN) + (ErrorReg * PROP_GAIN);
>
>This is overflowing an intermediate result. How do you debug?
Sometimes, not very well...
But for this situation I would assert properties of the expression, or better,
of each intermediate term.
So for example, (ErrorReg * PROP_GAIN) might have its own intermediate signal -
(in my code it almost certainly would - within the main process - so I can
control its pipelining but that's another story * ) - I could assert the output
sign matches the input sign (knowing, or asserting, PROP_GAIN is positive).
(* I've had summer interns exploring register retiming tools; they didn't beat
my hand-timed results. Which may say something about the tools, or not)
Then either I get a pinpoint report of the problem, or the testbench is
inadequate...
>> A better solution all round would be to replace it with an if-expression (in
>> which "if", "then", "else" are explicit, (don't rely on the reader knowing C)
>> and a case-expression for the (n>2) enumeration and integer subrange cases.
>>
>> But that seems to have fallen out of favour since Algol-W.
>
>I'm not sure what you are referring to. An if is a sequential control
>flow structure.
Maybe in some languages, but it doesn't have to be.
I used to be able to write code of the form
----
a := if <expr1> then <expr2> [ else <expr3>];
----
(the assignment being skipped if expr1 was false and there was no else clause)
and similarly, case expressions with semantics like case statements.
And I am delighted to hear it's on the way back in a mainstream language and one
of the main influences on VHDL.
>foo <= ralph + (('1' = Mode) ? A : B);
>
>compared to
>
>with Mode select
> foo <= ralph + A when '1',
> ralph + B when '0',
> (others => '-') when others;
I think a closer translation would be
foo <= ralph + A when Mode = '1' else ralph + B;
and I don't get the objection to that.
I doubt there's a synthesis tool alive that would duplicate the adder!
But if there were, I would mux A or B onto an intermediate signal .
>I don't get the "break" part. I think that is a subjective opinion.
>> >I don't get why you think the conditional operator would be a wart.
>> >It is just an operator. It is a trinary operator rather than uniary
>> >or binary,
>> For a start, what would the syntax for overloading it look like?
>
>Why would it be any different from what we currently use??? What does
>it look like?
What we currently use and overload are unary and binary operators. In neither of
these do you have to split the operator symbol in half and insert an argument in
the middle.
There is no syntax for expressing that, in VHDL.
That is what I mean by "break". I suspect we'd have to try writing the BNF for a
grammar that would handle its use and overloading to settle the question.
I confess I haven't looked to see how C++ overloads ?: That might be quite
illuminating...
>> And definitely not worth rewriting half the parser for one operator on one
>> specific enumerated type.
>
>Ok, now you are going off to unsubstantiated claims. I doubt anyone
>would agree to go with a feature that required rewriting half the
>compiler.
Maybe so, my compiler writing days are long ago. But something about adding
*one* trinary operator sets off alarm bells.
- Brian
Article: 147523On Wed, 28 Apr 2010 12:33:21 +0100, Alan Fitch <alan.fitch@spamtrap.com> wrote: >And VHDL 2008 provides various matching operators that allow std_logic, >bit and so on to be interpreted as Boolean - see >http://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_ease/ Heh... It says (and I hope quoting this comes under the heading of fair use) ---------------------------------------------------------------------------------------------- How many times have you wanted to write something like this: if A and B then where A and B are STD_LOGIC? ... You have to write this instead: if A = '1' and B = '1' then VHDL-2008 introduces a new operator, ??....So you can now write this: if ?? A and B then ---------------------------------------------------------------------------------------------- I confess, on the odd occasion, to writing if A and B then anyway. Is it cheating to (ab)use overload resolution by return type, overloading "and" for std_logic args to return a boolean? >If you're interested in VHDL 2008, I recommend the book "VHDL 2008 - >Just the New Stuff" by Peter Ashenden and Jim Lewis. I'll definitely follow this up... - BrianArticle: 147524
On Apr 28, 7:16=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > austin <aus...@xilinx.com> wrote: > >Stephen, > > >Yes. > > >(Sorry, I am not in Marketing, but I think you are more likely to > >believe me regardless...) > > Austin, > Pleeeeeaase have lunch with marketing tomorrow and convince them to > get a cortex-M3 or cortex-M0 in a Spartan! > > -- > Failure does not prove something is impossible, failure simply > indicates you are not using the right tools... > nico@nctdevpuntnl (punt=3D.) > -------------------------------------------------------------- Cortex-M3 by itself without good chunk of flash memory on the same die is not that interesting. Unfortunately, flash is not compatible with silicon process used for modern Spartan devices. Also, according to my understanding, Cortex-M3 Physical IP libraries are not availably for geometries finer than 90nm. IMHO, negotiating reasonable deal with ARM w.r.t. Cortex-M1 licensing on Xilinx devices would make a lot more sense than incorporating Cortex-M3. I am thinking about selling Cortex-M1X-enabled chips at small price premium relatively to otherwise identical Spartan regular devices. Thus low-to-mid volume customers would be isolated from ATM licensing. High-volume customers could still buy license directly from ARM and run it on regular Spartan. And, of course, all new Virtex devices should be Cortex-M1X-enabled - they cost enough already to justify that little gift to the customers. Now how to implement it technically I don't know exactly. Probably by mean of secret authentication key embedded both into M1X-enabled silicon and into encrypted variant of processor IP. P.S. Last time I talked to Altera representatives they hinted that Altera is going to announce exactly what you're asking for. Still, I don't think it is a good idea. The only thing that could make it useful would be some sort of flexible bootloader for ARM core from external serial flash that have to act independently from the main FPGA fabric. P.P.S. Not that I like Xilinx decision to embed dual-Cortex-A9. Cortex-A9 is a damn nice core, but it is too big, too hot to unpredictable (heavily relying on two levels of cache memory and dynamic branch prediction) and overall an overkill for sorts of applications that I want to run within FPGA. Cortex-R4F looks like better fit. But then again, may be Cortex-R4F is too similar feature-wise to PPC cores that they had in previous generations of Virtex, According to my understanding, those PPC cores were nor considered a major success story.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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