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
Quadibloc wrote:
> On Mar 5, 12:44 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>> Quadibloc <jsav...@ecn.ab.ca> writes:
>>> On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>>> No, he's saying that C doesn't really implement an array type, the
>>>> var[offset] syntax is just syntactic sugar for *(var + offset) which is why
>>>> things like 3[x] work the same as x[3] in C.
>>> Um, no.
>>> x = y + 3 ;
>>> in a C program will _not_ store in x the value of y plus the contents
>>> of memory location 3.
>>> On a big-endian machine,
>>> long int x[5] ;
>>> x[0] = 3 ;
>>> x[1] = 12 ;
>>> y = x[0] ;
>>> or, on a little-endian machine,
>>> long int x[5] ;
>>> x[1] = 3 ;
>>> x[0] = 12 ;
>>> y = x[1] ;
>>> will not result in zero being stored in y, since a long int variable
>>> occupies more than one byte in storage, and hence the two assignments
>>> are being made to overlapping variables.
>>> Yes, C doesn't do _bounds checking_, but that is a far cry from
>>> "syntactic sugar for variable plus address offset".
>> I'm not quite sure what the point of your example is, somebody who is
>> better at programming languages than me would have to evaluate the claim
>> that C arrays aren't arrays. But:
>>
>> #include <stdio.h>
>> int main()
>> {
>> int a[4];
>>
>> printf("a[2] at 0x%8x\n", &(a[2]));
>> printf("2[a] at 0x%8x\n", &(2[a]));
>> printf("(a+2) is 0x%8x\n", a+2);
>> printf("(2+a) is 0x%8x\n", 2+a);
>>
>> }
>>
>> [pfeiffer@snowball ~/temp]# ./awry
>> a[2] at 0xbfff97b8
>> 2[a] at 0xbfff97b8
>> (a+2) is 0xbfff97b8
>> (2+a) is 0xbfff97b8
>
> The 2[a] syntax actually *works* in C the way it was described? I am
> astonished. I would expect it to yield the contents of the memory
> location a+&2 assuming that &2 can be persuaded to yield up the
> location where the value of the constant "2" is stored.
>
> Evidently there is some discrepancy between C and FORTRAN.
>
> John Savard
Yes, "2[c]" does work in C as well as "c[2]", and yields the same
results. The definition of "c[x]" is "*(c+x)", where the array "c"
becomes a pointer to the first element, and the integer value "x"
is scaled by the length associated with the pointer "c". "*(c+x)"
will give the same result as "*(x+c)", so it's logical.
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
Article: 146151Walter Bushell wrote: > In article <20100305171635.e538ef18.steveo@eircom.net>, > Ahem A Rivet's Shot <steveo@eircom.net> wrote: > >> On Fri, 5 Mar 2010 09:07:31 -0800 (PST) >> Quadibloc <jsavard@ecn.ab.ca> wrote: >> >>> On Feb 26, 4:56Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote: >>> >>>> Â Â Â Â No, he's saying that C doesn't really implement an array type, >>>> the var[offset] syntax is just syntactic sugar for *(var + offset) >>>> which is why things like 3[x] work the same as x[3] in C. >>> Um, no. >>> >>> x = y + 3 ; >>> >>> in a C program will _not_ store in x the value of y plus the contents >>> of memory location 3. >> No but x = *(y + 3) will store in x the contents of the memory >> location at 3 + the value of y just as x = y[3] will and x = 3[y] will, >> which is what I stated. You missed out the all important * and ()s. > > No, that will compare x and the right val. > > = is a comparasion operator in c. > "==" is a comparison operator in c. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+Article: 146152
Peter Flass wrote: > Walter Bushell wrote: >> In article <20100305171635.e538ef18.steveo@eircom.net>, >> Ahem A Rivet's Shot <steveo@eircom.net> wrote: >> >>> On Fri, 5 Mar 2010 09:07:31 -0800 (PST) >>> Quadibloc <jsavard@ecn.ab.ca> wrote: >>> >>>> On Feb 26, 4:56Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote: >>>> >>>>> Â Â Â Â No, he's saying that C doesn't really implement an >>>>> array type, >>>>> the var[offset] syntax is just syntactic sugar for *(var + offset) >>>>> which is why things like 3[x] work the same as x[3] in C. >>>> Um, no. >>>> >>>> x = y + 3 ; >>>> >>>> in a C program will _not_ store in x the value of y plus the contents >>>> of memory location 3. >>> No but x = *(y + 3) will store in x the contents of the memory >>> location at 3 + the value of y just as x = y[3] will and x = 3[y] will, >>> which is what I stated. You missed out the all important * and ()s. >> >> No, that will compare x and the right val. >> >> = is a comparasion operator in c. >> > > '=' is assignment, '==' is comparison. I think there is *not* a single C programmer who has *not* had his hand slapped by making the mistake of using "=" when he meant "==". Thus the avalanche of replies... :-) -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+Article: 146153
> > What do you gain by trying to have tidy intermediate folders? > > as you said, tidiness... > tidy intermediate folders...i.e. folders that are not important to me as the user of the tool, but are needed by the tool to do it's job. In other words, I don't care if the tool's private folders are tidy or not. > I use separate libraries for major categories within the design; e.g. memory > interface, core logic, common (reusable) blocks, testbench - not separate > libraries for foo, bar and bletch. > My point was why even bother to separate them unless there are name clashes...or perhaps you're creating your own separate IP for resale and want to avoid clashes with some other potential IP. > I can't say it buys me a whole lot I agree > but it does help me keep the design hierarchy > straighter - e.g. if the synthesis project contains something from the Testbench > library, the design has gone seriously astray somewhere! > If it's actually a problem, the synthesis tool will complain quickly (like less than 1 minute into the run)...but the synthesis tool won't be looking at any libraries (testbench or other) it will create the libraries itself based on the source files you tell it are in there to be synthesized. Whether you compile such a testbench file into 'work' or 'testbench' won't matter. If the source file is included it will be analyzed. If it happens to be synthesizable code (even if it is only intended for sim testbench) synthesis will be OK with it. It won't generate any logic from this extraneous code since it won't be called from within the hierarchy of the design to be synthesized. I confess though, I'm not quite sure what your point is here for compiling stuff into separate libraries. It *sounds* like you're talking about organizing source files into separate 'libraries'...in which case what you said would make more sense but that's not at all the same thing as compiling something into a library other than 'work'. Kevin JenningsArticle: 146154
In comp.arch.fpga Rick <richardcortese@gmail.com> wrote: (snip) > One of the other old processors from my stone knives and bear skin > days was the RCA1802. It had IMHO a great feature for the calling > subroutines. Anyone of the 16 general purpose registers could be made > the program counter with a single instruction. The OS/360 (and successor) calling mechanism isn't so different. The BALR instruction branches to the address in a specified register, while storing the address of the next instruction in a register. It is even allowed for both registers to be the same! I have seen that used for coroutines, where an appropriate BALR switches between routines using only one register to store the address in the other routine. --glenArticle: 146155
Quadibloc <jsavard@ecn.ab.ca> writes: > > The 2[a] syntax actually *works* in C the way it was described? I am > astonished. I would expect it to yield the contents of the memory > location a+&2 assuming that &2 can be persuaded to yield up the > location where the value of the constant "2" is stored. I don't have my copy handy, but I think it was documented that way back in the original C language Bell Labs tech report. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)Article: 146156
Charles Richmond <frizzle@tx.rr.com> writes: > Peter Flass wrote: > > Walter Bushell wrote: > >> In article <20100305171635.e538ef18.steveo@eircom.net>, > >> Ahem A Rivet's Shot <steveo@eircom.net> wrote: > >> > >>> On Fri, 5 Mar 2010 09:07:31 -0800 (PST) > >>> Quadibloc <jsavard@ecn.ab.ca> wrote: > >>> > >>>> On Feb 26, 4:56Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote: > >>>> > >>>>> Â Â Â Â No, he's saying that C doesn't really implement an > >>>>> array type, > >>>>> the var[offset] syntax is just syntactic sugar for *(var + offset) > >>>>> which is why things like 3[x] work the same as x[3] in C. > >>>> Um, no. > >>>> > >>>> x = y + 3 ; > >>>> > >>>> in a C program will _not_ store in x the value of y plus the contents > >>>> of memory location 3. > >>> No but x = *(y + 3) will store in x the contents of the memory > >>> location at 3 + the value of y just as x = y[3] will and x = 3[y] will, > >>> which is what I stated. You missed out the all important * and ()s. > >> > >> No, that will compare x and the right val. > >> > >> = is a comparasion operator in c. > >> > > > > '=' is assignment, '==' is comparison. > > I think there is *not* a single C programmer who has *not* had his > hand slapped by making the mistake of using "=" when he meant > "==". More than once... -- PatrickArticle: 146157
"Quadibloc" <jsavard@ecn.ab.ca> wrote in message news:91a047d3-ee98-40b6-876e-9a7221168d5b@33g2000yqj.googlegroups.com... > The 2[a] syntax actually *works* in C the way it was described? I am > astonished. I would expect it to yield the contents of the memory > location a+&2 assuming that &2 can be persuaded to yield up the > location where the value of the constant "2" is stored. > Evidently there is some discrepancy between C and FORTRAN. Yes, it really does work as described, and was indeed documented in the earliest C, and for that matter B and BCPL manuals. C and Fortran are discrepant here. DennisArticle: 146158
On Mar 5, 11:51=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 4, 3:14 pm, Andy Peters <goo...@latke.net> wrote: > > > On Mar 4, 11:56 am, Antti <antti.luk...@googlemail.com> wrote: > > > > as Xilinx has dropped hard processor IP in the latest families it > > > makes ACTEL the only FPGA vendor whos latest product family does have > > > hard processor IP. > > > Putting a processor inside an FPGA has proven to us to be a bigger > > PITA than it's worth. > > Who exactly is "us"? =A0Are you with Xilinx, Actel or someone else? > > > Consider than instead of V4FX, you can use an S3AN and a standalone > > PPC and you'll pay a whole lot less. Plus the various Freescale PPCs > > have DDR memory and Ethernet and DMA controllers that don't suck, and > > you're not stuck with crappy tools. > > > Embedding the processor in the FPGA is an interesting idea, but as > > long as Brand X seems to think that the only people who do are the > > types who want to run Linux on an FPGA, it's gonna suck for actual > > embedded use. > > The big problem seems to be the problem of too many size combinations > to be practical. =A0Mixing FPGA, CPU, SRAM and Flash on one chip can't > be all things to all people. =A0Still, I think there are a few sweet > spots that can be profitable. =A0A smallish FPGA (~3000 to 5000 LUT4s) > combined with a CM3 in the typical MCU memory combinations is a > powerful device, especially if it is available with a decent dual > CODEC in a package on the smaller side (100 pins or less). =A0The cost > of low end FPGAs seem to be I/O count driven, so a 5000 LUT4 FPGA can > likely be combined with a CM3 (or maybe a CM0), etc, without > increasing the cost significantly. =A0I am paying $10 for a 3000 LUT4 > FPGA in a 100 TQFP along with a $3 stereo CODEC. =A0If I could get an > MCU in that package with even just 64 kB of Flash it would allow a > very space constrained product to really have some capabilities... if > they could keep the cost down to $15 at qty 100. > > Other than Cypress, no one else seems to see this as a viable market. > I'm still waiting to see if the Cypress PSOC5 is all its cracked up to > be. =A0The Actel parts are way too expensive from what I've heard and I > think the PSOC5 will be too rich as well. > > Rick The PSoC5 looks interesting, but the EMIF interface is pretty limited. The external memory bus is restricted to a 32MHz clock, due to the pad I/O apparently, and is hardwired to require two clock cycles per access. This might be livable if the EMIF core had a ZBT or FIFO option, but everything I've seen so far indicates that it only supports traditional async and sync SRAM. The only saving grace is that it can be 16-bits wide, giving you 32MB/s to an external host. 32MB/s is nothing to sneeze at for a lot of designs, but it would have been nice to see them find a clever way to double that - even if it meant DDR techniques. I'm actually looking at putting together a little breadboard with a PSoC5 and a Cyclone III to play around with, and see what kind of sustained data rates can be achieved - once Cypress gets around to sampling them and updates Creator with the EMIF core. I'll probably emulate a sync SRAM in the FPGA, and memory map the I/O. Of course, the real advantage of the PSoC's is the extremely flexible analog. Strapping a 20-bit del-sig ADC to anything can be absurdly expensive, and you are generally stuck with it once you put it down. The PSoC, on the other hand, lets you trade speed for resolution, and play all kinds of games with the clocks; after the board is done - and generally create the "perfect" analog hardware for the task on-chip. Even better, you can do it on the fly by poking the configuration registers with software. If they are even close to being as good as Cypress claims, I've got lots of jobs for them.Article: 146159
Quadibloc schrieb:
> On Mar 5, 12:44 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>> #include <stdio.h>
>> int main()
>> {
>> int a[4];
>>
>> printf("a[2] at 0x%8x\n", &(a[2]));
>> printf("2[a] at 0x%8x\n", &(2[a]));
>> printf("(a+2) is 0x%8x\n", a+2);
>> printf("(2+a) is 0x%8x\n", 2+a);
>>
>> }
>>
>> [pfeiffer@snowball ~/temp]# ./awry
>> a[2] at 0xbfff97b8
>> 2[a] at 0xbfff97b8
>> (a+2) is 0xbfff97b8
>> (2+a) is 0xbfff97b8
>
> The 2[a] syntax actually *works* in C the way it was described? I am
> astonished. I would expect it to yield the contents of the memory
> location a+&2 assuming that &2 can be persuaded to yield up the
> location where the value of the constant "2" is stored.
You can think of the "a" in "a[4]" as a named numerical (integer)
constant (alias), giving the address of the memory block that was
allocated by the definition.
So there is no difference, between using that (named) constant or an
explicit numerical constant.
The only differences between:
(1) int a[4];
and:
(2) int * a = malloc( 4 * sizeof(int));
is the place where the memory is allocated and the value in (2) may be
changed later. (And the amount of typing, ofcourse!)
In both cases you can use "a[1]" or "*(a+1)" for access.
> Evidently there is some discrepancy between C and FORTRAN.
Only "a tiny bit"! ;-)
Grüße,
Uwe
Article: 146160On Sat, 06 Mar 2010 15:03:52 -0500 Walter Bushell <proto@panix.com> wrote: > No, that will compare x and the right val. > > = is a comparasion operator in c. Bzzzt wrong! -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/Article: 146161
On Sat, 6 Mar 2010 01:58:43 -0800 (PST) Quadibloc <jsavard@ecn.ab.ca> wrote: > On Mar 5, 10:16Â am, Ahem A Rivet's Shot <ste...@eircom.net> wrote: > > > Â Â Â Â No but x = *(y + 3) will store in x the contents of the memory > > location at 3 + the value of y just as x = y[3] will and x = 3[y] will, > > which is what I stated. You missed out the all important * and ()s. > > Intentionally. My point was that, while there is _some_ truth to the > claim that C arrays tread rather lightly on the ground of hardware > addressing, the claim that C doesn't have arrays at all, and the C > array subscript operator does nothing at all but add two addresses > together... is not *quite* true. The C subscript operator does do nothing other than adding two numbers and dereferencing the result, that last action is rather important. The validity of constructs like 2[a] and *(2+a) make this clear - as does the equivalence of a and &(a[0]) or of *a and a[0] where a is a pointer. C does have good support for pointers and adding integers to pointers and for declaring blocks of storage with an array like syntax. > If C doesn't have "real" arrays, it at least makes a rather good Arrays are not a real type in C if they were they would be passed by value in function calls instead of being passed by reference and it would be necessary to use a construct like &(a[0]) to pass the address of the first element of the array instead of just a. > attempt to simulate them. Unless one's standards are such that FORTRAN > doesn't quite have "real" arrays either, and you need to go to Pascal > for real arrays, there isn't that much to complain about in the case > of C. I am not saying that the C arrays are not useful as they are, just that they fall short of being a type in the sense that int, char, long, pointer and struct are. -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/Article: 146162
On Sat, 6 Mar 2010 02:01:30 -0800 (PST) Quadibloc <jsavard@ecn.ab.ca> wrote: > The 2[a] syntax actually *works* in C the way it was described? I am > astonished. I would expect it to yield the contents of the memory > location a+&2 assuming that &2 can be persuaded to yield up the > location where the value of the constant "2" is stored. Yes of course it does - why else would I have mentioned it in my first post in this threadlet ? a is a pointer, 2 is in a integer and 2[a] is the same as a[2] is the same as *(a+2) and the rules for adding pointers and integers are well defined in C. This is the heart of my original point, array notation in C is syntactic sugar for pointer arithmetic (and also for allocation which I neglected to mention in my original post). -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/Article: 146163
Hi, all I have a question in the testbench written by verilog. Why we always define the inputs of MUT as reg and outputs of MUT as wire, just the opposite with the in/output definition in verilog modules. So more clearly, what are the basic issues that I should know when I have to decide the type of a variable(reg or wire)? Thanks FrankArticle: 146164
If you can get it the T9900 is better than T9800 but they are fairly rare with most companies seem to push the quad core instead. I have not got a mobile I7 yet but we do have desktop I7 and they have been very good. Laptops using the desktop I7 have been a definate no on battery lifetime of 1hr being typical but when I get the chance I will try the mobile I7 as it promises much. Parallel processors will be more use in a couple of years when tools have better use of them. On OS I think there are X64 drivers but I would only go that way if I had a really large design to deal with. Bugs and problems are far more common in X64 and Linux versions of the tools and with the relatively tiny user base bugs can take a while to surface and dare I say it get fixed. Life is busy enough without adding unnecessary problems. John Adair Enterpoint Ltd. On 6 Mar, 21:45, Michael S <already5cho...@yahoo.com> wrote: > On Mar 6, 5:37 pm, John Adair <g...@enterpoint.co.uk> wrote: > > > I7 laptops if you can get the mobile versions are best but do watch > > the battery lifetime. Most software isn't using the multiple cores so > > the next best Core2 duo (T9800) based can be good too. > > Why not T9900? > At single FPGA compilation it should easily beat any 35W member of > core-i7 family, including i7-620M. FPGA tools love on-chip cache above > anything else. In fact, it's possible that even T9600 is faster than > i7-620M. > i7-820QM would be faster, yet, but at 45W TDP you will likely find it > only in special heavyweight models. > > Of course, if you often find yourself compiling several variants in > parallel, stick with i7/i5, since in that scenario core2duo is pretty > weak. > > >Have a look at > > a HP 8730w for one based on T9800. This can go 3-4hrs and double that > > with an extension battery they have that clips on. That's series > > computing on battery for most of a normal man's working day. There are > > quad core ones too but I don't think the extra money is worth > > spending. Better to spend money on a good SSD drive which are great > > for making things go faster too if you can get the right one. > > > HP are going to release a 8740w at some point in time. Hopefully soon > > and that is I7 based from what little is in the public domain. > > > HP are still offering XP downgrades last time I looked if you want to > > use Windows as OS. That is one the reasons I use them. Dell do the > > same. > > Do they offer XP64 drivers? > XP32 is sufficient in for 98% of todays FPGA but the upper 2% (the > biggest Stratix-IV devices, for example) require 64-bit tools. > > > > > John Adair > > Enterpoint Ltd.Article: 146165
You need to set the type according to how it will be assigned a value. reg if written to in an always or initial block, wire otherwise. Cheers, JonArticle: 146166
On Sun, 7 Mar 2010 01:56:22 -0800 (PST), Frank wrote:
[We really must write this up as a FAQ.....]
>I have a question in the testbench written by verilog. Why we always
>define the inputs of MUT as reg and outputs of MUT as wire,
Not "always". The MUT (DUT) outputs must be connected to wires,
but the inputs can be connected either to reg or to wire - it's
your choice.
>opposite with the in/output definition in verilog modules.
It is sometimes that way, but don't worry about it. That
is not the basic problem. See below.
>So more clearly, what are the basic issues that I should know when I
>have to decide the type of a variable(reg or wire)?
The rules are extremely simple:
****************************************************************
* If an object is given its value by assignment in procedural *
* code, then that object must be a variable (reg). *
* *
* If an object is given its value by any other method, then *
* that object must be a net (wire). *
****************************************************************
However, it is often difficult to get this exactly right
in practice.
First there is the problem of definition. In my wording
of the rules, above, what do I mean by "assignment in
procedural code"?
- The thing on the left-hand side of an assignment (= or <=)
in the body of an always, initial, task or function;
- anything that is passed to a task's inout or output
argument.
"Given its value by any other method" means any of these:
- it is connected to an output or inout port of a module instance;
- it is connected to an output or inout port of a UDP or
primitive instance;
- it is the left-hand side of a continuous assignment ("assign")
statement at the top level of a module;
- it is an input or inout port of a module.
As a result of the rules.....
- Inside a module, any inout or input ports must be a net (wire)
because it gets its value from whatever you connect to the
port when you instance the module.
- Inside a module, an output port can be either a net (wire)
or a variable (reg); the choice depends on how that thing
gets its value within the module's code. The value of the
thing is passed out through
the port to the wire you connect on the outside.
- When you create an instance of a module, you must connect
wires to all its output and inout ports because those wires
get their value by connection, not by procedural assignment.
- When you create an instance of a module, you are free to connect
either a wire or a reg to its input port. The choice depends
on how that thing gets its value in your outer module.
Hope this helps. Note that the rules are slightly different in
SystemVerilog, but it's a good idea to learn the Verilog basics!
--
Jonathan Bromley
Article: 146167Ahem A Rivet's Shot <steveo@eircom.net> writes: > On Sat, 6 Mar 2010 01:58:43 -0800 (PST) > Quadibloc <jsavard@ecn.ab.ca> wrote: > >> On Mar 5, 10:16 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote: >> >> > No but x = *(y + 3) will store in x the contents of the memory >> > location at 3 + the value of y just as x = y[3] will and x = 3[y] will, >> > which is what I stated. You missed out the all important * and ()s. >> >> Intentionally. My point was that, while there is _some_ truth to the >> claim that C arrays tread rather lightly on the ground of hardware >> addressing, the claim that C doesn't have arrays at all, and the C >> array subscript operator does nothing at all but add two addresses >> together... is not *quite* true. > > The C subscript operator does do nothing other than adding two > numbers and dereferencing the result, that last action is rather important. > The validity of constructs like 2[a] and *(2+a) make this clear - as does > the equivalence of a and &(a[0]) or of *a and a[0] where a is a pointer. Yet when dereferencing arrays of rank >= 2, dimensions are automatically incorporated into the effective address, so its not quite equivalent to a simple addition of pointer and offset. GregmArticle: 146168
On Sat, 6 Mar 2010 17:26:24 -0800 (PST), KJ <kkjennings@sbcglobal.net> wrote: >I confess though, I'm not quite sure what your point is here for >compiling stuff into separate libraries. It *sounds* like you're >talking about organizing source files into separate 'libraries'...in >which case what you said would make more sense but that's not at all >the same thing as compiling something into a library other than >'work'. You can't keep source files in separate libraries - separate folders, yes, hence (I presume) your quotes around 'libraries'. While I do that, I also tend to use a VHDL library structure that reflects the same source folder structure and design intent. Except when tool bugs prevent it. It's really mostly habit, a satisfactory (to me) way of working acquired back in my Modula-2 days. I'm not making wild claims that it's better in any substantial way, but VHDL was designed to allow compilation into separate libraries... Speculating why, it would presumably have allowed compiled libraries to have been re-used across multiple projects, in the days when compilation and synthesis were expensive operations. Nowadays, that is trivially unimportant, except for the highly optimised treatments given to standard libraries. Tools could make use of it for distributing IP as compiled libraries instead of source, but they don't... ... aah, that must be it - I'm just waiting for the tools to catch up! ;-) - BrianArticle: 146169
On Mar 7, 1:45=A0am, Ahem A Rivet's Shot <ste...@eircom.net> wrote: > On Sat, 6 Mar 2010 02:01:30 -0800 (PST) > > Quadibloc <jsav...@ecn.ab.ca> wrote: > > The 2[a] syntax actually *works* in C the way it was described? I am > > astonished. I would expect it to yield the contents of the memory > > location a+&2 assuming that &2 can be persuaded to yield up the > > location where the value of the constant "2" is stored. > > =A0 =A0 =A0 =A0 Yes of course it does - why else would I have mentioned i= t in my > first post in this threadlet ? a is a pointer, 2 is in a integer and 2[a] > is the same as a[2] is the same as *(a+2) and the rules for adding pointe= rs > and integers are well defined in C. This is the heart of my original poin= t, > array notation in C is syntactic sugar for pointer arithmetic (and also > for allocation which I neglected to mention in my original post). If a[2] was the same as *(a+2), then, indeed, since addition is commutative, it would make sense that 2[a], being the same as *(2+a), would be the same. But a[2] is the same as *(&a+2) which is why I expected 2[a] to be the same as *(&2+a). Unless in *(a+2) "a" suddenly stops meaning what I would expect it to mean. In that case, C has considerably more profound problems than not having arrays. John SavardArticle: 146170
What's the minimum clock pulse width I can drive into a Spartan 3 global clock input via LVDS? I'm using the -5 speed grade device with VDDC cranked up to 1.25V. I've currently got it working at 200 MHz ~ 50% duty = 2.5ns pulses; but I want to lower the duty cycle. Can I squeeze the pulses to below 2ns? I can't test this without re-spinning my board. I see sub-nanosecond minimum clock widths and 720 MHz maximum toggle rates in the datasheet; but I also see max 10pF input capacitance. 50% duty cycle keeps the swing centred on VCM; but I lose that advantage with my low duty cycle. I still reckon it should work; but it would be good to hear from others who've pushed these limits. TIAArticle: 146171
On Mar 7, 6:39=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Sun, 7 Mar 2010 01:56:22 -0800 (PST), Frank wrote: > > [We really must write this up as a FAQ.....] > thank you, that really helps:)Article: 146172
On Mar 7, 12:25 pm, John Adair <g...@enterpoint.co.uk> wrote: > If you can get it the T9900 is better than T9800 but they are fairly > rare with most companies seem to push the quad core instead. > > I have not got a mobile I7 yet but we do have desktop I7 and they have > been very good. Sure, desktop I7 are fast. With 8MB of cache and not so heavy reliance on turbo-boost one can expect them being fast. On the other hand, 35W mobile variants have 4MB or smaller cache and are critically dependent on turbo-boost, since relatively to mobile C2D their "normal" clock frequency is slow. Still, it just my guts feeling, I never benchmarked mobile i7 vs mobile C2D, so I could be wrong about their relative merits. > Laptops using the desktop I7 have been a definate no > on battery lifetime of 1hr being typical but when I get the chance I > will try the mobile I7 as it promises much. Parallel processors will > be more use in a couple of years when tools have better use of them. > > On OS I think there are X64 drivers but I would only go that way if I > had a really large design to deal with. Bugs and problems are far more > common in X64 and Linux versions of the tools and with the relatively > tiny user base bugs can take a while to surface and dare I say it get > fixed. Life is busy enough without adding unnecessary problems. > > John Adair > Enterpoint Ltd. > For the last year or so we do nearly all our FPGA development on Ws2003/x64. So far, no problems. Even officially deprecated Rainbow (now SafeNet) USB Software Guards work fine. XP64 is derived from the same code base. We almost never use 64-bit tools, but very much appreciate the ability to launch numerous instances of memory-hungry 32-bit tools. More a matter of convenience than necessity? In single-user environment, yes. But why should we give up convenience that costs so little?Article: 146173
"Andrew Holme" <ah@nospam.com> wrote: >What's the minimum clock pulse width I can drive into a Spartan 3 global >clock input via LVDS? I'm using the -5 speed grade device with VDDC cranked >up to 1.25V. I've currently got it working at 200 MHz ~ 50% duty = 2.5ns >pulses; but I want to lower the duty cycle. Can I squeeze the pulses to >below 2ns? I can't test this without re-spinning my board. I see >sub-nanosecond minimum clock widths and 720 MHz maximum toggle rates in the >datasheet; but I also see max 10pF input capacitance. 50% duty cycle keeps >the swing centred on VCM; but I lose that advantage with my low duty cycle. >I still reckon it should work; but it would be good to hear from others >who've pushed these limits. Isn't there a duty cycle limit in the datasheets? I did have some problems driving a 100MHz clock at CMOS level into a Spartan 3. It turned out the duty cycle was around 30% because the driver couldn't handle 100MHz. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 146174
On Sun, 07 Mar 2010 06:11:07 -0800, Michael S wrote: > On Mar 7, 12:25 pm, John Adair <g...@enterpoint.co.uk> wrote: >> If you can get it the T9900 is better than T9800 but they are fairly >> rare with most companies seem to push the quad core instead. >> >> I have not got a mobile I7 yet but we do have desktop I7 and they have >> been very good. > > Sure, desktop I7 are fast. With 8MB of cache and not so heavy reliance > on turbo-boost one can expect them being fast. On the other hand, 35W > mobile variants have 4MB or smaller cache and are critically dependent > on turbo-boost, since relatively to mobile C2D their "normal" clock > frequency is slow. Still, it just my guts feeling, I never benchmarked > mobile i7 vs mobile C2D, so I could be wrong about their relative > merits. > >> Laptops using the desktop I7 have been a definate no on battery >> lifetime of 1hr being typical but when I get the chance I will try the >> mobile I7 as it promises much. Parallel processors will be more use in >> a couple of years when tools have better use of them. >> >> On OS I think there are X64 drivers but I would only go that way if I >> had a really large design to deal with. Bugs and problems are far more >> common in X64 and Linux versions of the tools and with the relatively >> tiny user base bugs can take a while to surface and dare I say it get >> fixed. Life is busy enough without adding unnecessary problems. >> >> John Adair >> Enterpoint Ltd. >> >> > For the last year or so we do nearly all our FPGA development on > Ws2003/x64. So far, no problems. Even officially deprecated Rainbow (now > SafeNet) USB Software Guards work fine. XP64 is derived from the same > code base. > We almost never use 64-bit tools, but very much appreciate the ability > to launch numerous instances of memory-hungry 32-bit tools. More a > matter of convenience than necessity? In single-user environment, yes. > But why should we give up convenience that costs so little? I have benchmarked Core2s vs iCore7s. 6M Cache iCore2s are faster on a clock for clock basis then the 8M Cache iCore7 when running NCVerilog. The iCore7 is a little faster on a clock for clock basis when running Xilinx place and route tools. The cache architecture of the iCore7 sucks, it's a three level cache vs a two level cache on the Core2. Also there is less cache per processor on the iCore7 (2M) then the Core2 (3M) so the degradation in performance is greater. Finally the absolute clock rate for the Core2s is higher then it is for the iCore7, combine that with the faster clock for clock simulation performance and the Core2 is the clear winner for FPGA development.
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