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 Feb 26, 6:30=A0am, "Nial Stewart" <nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote: > > =A0The > > settings include current drive of 4, 8, 12, 16 and 20 mA along with > > speed settings of FAST and SLOW. =A0Clearly you can't just do a > > calculation based on the rated current since that would leave no room > > for the FAST/SLOW setting. > > I might be wrong, but I _think_ that in Quartus a FAST or SLOW assignment > overrides the current setting, so that's fewer variations to worry about. > > > I am left only > > with building 10 different bit files, loading up 10 different boards > > and taking 10 measurements. =A0Not my idea of a fun afternoon. > > Sure it wouldn't take too long to knock up a mickey mouse design that > just toggles a single pin then vary the assignments. You could have a new > test re-built and programmed in a minute or two. > > Or are there other constraints? > > Nial. I don't need to knock up a "Mickey Mouse" design to test. I can use my standard design. But it is not so easy because I will have to program 10 boards with 10 different configurations to do this and take them to my customer's facility to test. I supply him with boards, he doesn't supply me with his system. RickArticle: 145876
> I don't need to knock up a "Mickey Mouse" design to test. The point of 'mickey mouse' is that you can P&R in a matter of seconds. Do a test, re-run P&R and do the next test in less than a couple of minutes. Less than an hour for all the tests including the initial mickey mouse and time for a cup of tea. > I can use > my standard design. But it is not so easy because I will have to > program 10 boards with 10 different configurations to do this and take > them to my customer's facility to test. I supply him with boards, he > doesn't supply me with his system. OK, so the other constraint is that you can't do the measurement then quickly re-program the FPGA? Nial.Article: 145877
Charles Richmond wrote: > A "thunk" was *and* is a method for implementing "call by name". But a > compiler providing "thunks" has *not* been written for some time now. That's rather dubious. We don't know that no one has written a compiler that provides ALGOL-style thunks recently. To demonstrate that you'd have to prove a negative. If we relax the definition to allow named as well as anonymous functions, then someone could argue that get-accessors for properties are thunks, and those are quite common in modern languages. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145878
Ahem A Rivet's Shot 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. That's not quite correct. C does implement an array type (or, rather, an array type qualifier which can be used to implement arrays of any object type); it's just not first-class. Array access syntax is syntactic sugar for multiply-add-dereference, but arrays aren't just syntactic sugar, because array definitions reserve storage and permit initialization. Also, array and pointer lvalues are interpreted differently, even in contexts where they former decays to the latter, which is why an external array declaration is not equivalent to an external declaration of a pointer to the same object type.[1] Array types aren't first-class because when used as formal parameters they're converted to pointer types, and when used as actual parameters they decay to a pointer to their first element. This is similar to C's other second-class type, the function type, which decays to a function pointer in every context except declaration and definition. [1] Probably the best treatment of this question is in PvdL's _Expert C Programming_, chapter 4, "The Shocking Truth: C Arrays and Pointers Are NOT the Same!", and chapter 9, "More About Arrays". -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145879
(see below) wrote: > On 24/02/2010 20:37, in article hm6fbd68gp@news6.newsguy.com, "Michael > Wojcik" <mwojcik@newsguy.com> wrote: > >> (see below) wrote: >>> But bear in mind that in decent languages arrays are >>> storable values, so a value array parameter gets copied in toto, unlike C. >> It will be in C if the array is wrapped in a struct. Letting array > > That is passing a struct, not an array. Yes, that's what I said. Of course, if the array is the only thing in the struct, then the distinction is purely syntactic. >> struct (and not the misnamed "typedef") is C's mechanism for creating >> new types and ADTs, so if you want a pass-by-value array in C, the >> correct thing to do is to put it in a struct. > > Yes. Preposterous, isn't it? Other than the name of the keyword struct, no, it seems pretty reasonable to me. Parameters should be primitives or ADTs. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145880
If you were all wondering why we have not had stock recently on this board we took some feedback and then took the opportunity to shoehorn some more features into this board. We have improved the LVDS features of the board, and added the following 20 more I/O on an IDC 40 way DS1306 RTC with battery holder MicroSD slot Mounting holes (compatible with Drigmorn2) The LCD can now also be replaced by 2x17 IDC for OEM orders as well allowing a semi-remote interface. Full details and an updated picture http://www.enterpoint.co.uk/drigmorn/drigmorn3.html. Stock should be available from later next week. John Adair Enterpoint Ltd.Article: 145881
Scott Lurndal wrote: > > I've never promoted or suggested that one put an array in a struct > and pass it by value, I frankly think it would be a stupid thing to > do in a C program. Is it a stupid idea, or a good one, in all the languages that support it? Is this just a special attribute of C? > I was curious if anyone thought passing an array by value was a > _good_ idea. It might be if you want the callee to be able to modify its copy of the array without affecting the caller's. Just like any other pass-by-value object. If the callee would have had to make a copy of the array anyway, why not let the compiler do the work? -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145882
Joe Pfeiffer wrote: > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >> In comp.arch.fpga Scott Lurndal <scott@slp53.sl.home> wrote: >> >>> I've never promoted or suggested that one put an array in a struct >>> and pass it by value, I frankly think it would be a stupid thing to >>> do in a C program. >> It might make sense for a small array. You might have an rgb >> array dimensioned [3] instead of three separae variables. >> The dimension, I believe, has to be a compile time constant. > > It doesn't. You can use malloc() to allocate an arbitrary-sized buffer, > and then use array syntax to access elements of the buffer. You can > also pass the address of the buffer, and use it like an array in the > called procedure. That doesn't work for a pass-by-value array, which is what we're talking about here. You can only pass an array by value in C if it's an array type that's a member of a struct (or union, which is just a special case of struct). -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145883
glen herrmannsfeldt wrote: > In comp.arch.fpga Charles Richmond <frizzle@tx.rr.com> wrote: > (snip) > >> The dimensions of arrays *used* to have to be compile time >> constants. Now they have a type of array declared in a function >> that can have its size depend on an integer passed into the >> function. (I forget what they call it... maybe a "dynamic array" >> or something.) > > Yes, but can you do that for an array in a struct. No. The size of a struct type must be known at compile time, even in C99. > If you > pass it in a function call, and it isn't the last argument, how > will the called routine know where the other arguments are? If you *could* do this, that'd be an implementation issue, and outside the scope of the C language. :-) (Technically, C says nothing about a stack. A conforming C implementation could use activation frames that contain XML documents describing each parameter in detail. It could use an indexed file to implement the call stack. It could implement calls by generating subprograms on the fly that get their parameters via pipes. If they get there on the backs of unicorns ridden by nasal demons, that's OK with the standard too.) -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145884
Michael Wojcik <mwojcik@newsguy.com> writes: > Scott Lurndal wrote: >> >> I've never promoted or suggested that one put an array in a struct >> and pass it by value, I frankly think it would be a stupid thing to >> do in a C program. > > Is it a stupid idea, or a good one, in all the languages that support > it? Is this just a special attribute of C? > >> I was curious if anyone thought passing an array by value was a >> _good_ idea. > > It might be if you want the callee to be able to modify its copy of > the array without affecting the caller's. Just like any other > pass-by-value object. I think the point is that this is unlikely to be a good thing to do to an array. I'm not terribly sure it's often a good idea for anything else, either! > If the callee would have had to make a copy of the array anyway, why > not let the compiler do the work? -- 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: 145885
In comp.arch.fpga Michael Wojcik <mwojcik@newsguy.com> wrote:
(snip on C, arrays, and such)
> Array types aren't first-class because when used as formal parameters
> they're converted to pointer types, and when used as actual parameters
> they decay to a pointer to their first element. This is similar to C's
> other second-class type, the function type, which decays to a function
> pointer in every context except declaration and definition.
How do you classify Fortran arrays. (Specifically "assumed size"
arrays in newer Fortran versions, the only ones they had in older
versions.)
Since Fortran doesn't use call by value, but allows either call by
reference or call by value result, there is no need for the "decay
to pointer to the first element." The Fortran standard, since the
first standard in 1966, and still in Fortran 2008, allows one to
do things like:
dimension x(100)
call y(x(23))
and in the called routine
subroutine y(z)
dimension z(78)
where subroutine y gets the last 78 elements of array x. The effect
is exactly the same as a C program passing x+22 as a pointer.
It is also legal to pass an array element of a multidimensional
array to a called routine with a dummy array with a different number
of dimensions (rank on Fortran terms). It was very common for library
routines to dimension the dummy array (1) in the Fortran 66 days, or
(*) in later versions, and compute the appropriate offset in a two
(or more) dimensional actual argument (array in the calling routine).
Pointers were added to Fortran in Fortran 90, but don't have any
of these properties. You can't do all the pointer addition tricks
that you can do in C with them.
> [1] Probably the best treatment of this question is in PvdL's _Expert
> C Programming_, chapter 4, "The Shocking Truth: C Arrays and Pointers
> Are NOT the Same!", and chapter 9, "More About Arrays".
-- glen
Article: 145886On Feb 27, 1:43=A0am, Symon <symon_bre...@hotmail.com> wrote: > It would be impossible for a vendor to publish a 'rise time' for these > devices, because of the many different settings, which is why the IBIS > files are great. IBIS files are only great, if you can use them ;) Rick's issue illustrate a classic 'falling between two stools' problem. The info has got more complex, and so they defer to a IBIS model, but now that info, is only conditionally visible. (and worse, general experience has got lost to the software) There are plenty of free/cheap spice tools around, so there really should be a 'simplest common denominator' offering from the IC vendors, that allows usable 'quick checks' of port behavior, on all drive conditions. That's only a small amount of work needed at the IC vendor end, to fix a blind spot. -jgArticle: 145887
On 26/02/2010 18:51, in article hm95vg73v1@news5.newsguy.com, "Michael Wojcik" <mwojcik@newsguy.com> wrote: > (see below) wrote: >> On 24/02/2010 20:37, in article hm6fbd68gp@news6.newsguy.com, "Michael >> Wojcik" <mwojcik@newsguy.com> wrote: >> >>> (see below) wrote: >>>> But bear in mind that in decent languages arrays are >>>> storable values, so a value array parameter gets copied in toto, unlike C. >>> It will be in C if the array is wrapped in a struct. Letting array >> >> That is passing a struct, not an array. > > Yes, that's what I said. Of course, if the array is the only thing in > the struct, then the distinction is purely syntactic. > >>> struct (and not the misnamed "typedef") is C's mechanism for creating >>> new types and ADTs, so if you want a pass-by-value array in C, the >>> correct thing to do is to put it in a struct. >> >> Yes. Preposterous, isn't it? > > Other than the name of the keyword struct, no, it seems pretty > reasonable to me. Parameters should be primitives or ADTs. Ah. You are a fundamentalist. -- Bill Findlay <surname><forename> chez blueyonder.co.ukArticle: 145888
On Feb 27, 4:30=A0am, rickman <gnu...@gmail.com> wrote: > I don't need to knock up a "Mickey Mouse" design to test. =A0I can use > my standard design. =A0But it is not so easy because I will have to > program 10 boards with 10 different configurations to do this and take > them to my customer's facility to test. You could use the info you have already : You seem to have two corner cases, so some interpolation could reduce the passes a lot ? - How slow is 'ridiculously slow', what v/ns ? - How FAST is the fastest slew, and what ringing ? Drop those two into a vanilla I.LCR model in AnySpice, and verify your observations. Then, choose an intermediate drive level, and check if that does what you need. I also found this http://www.fpgarelated.com/usenet/fpga/show/90362-2.php so it is not a rare issue. -jgArticle: 145889
Rick, Must not be a Xilinx part, as our hotline engineers have copies of all popular signal integrity tools, and any webcase (from a paying customer: students and hobbyists might have to email me, or post their queury on our forums) that provides the needed information (part number, package, io type, drive strength, slew setting, pcb trace length, load) can request a "what if" sanity check answer (slew rate, overshoot, undershoot, SLOW/WEAK and FAST/STRONG IBIS process/voltage/ temperature corners).... You know my email, too, so if you had emailed me, you would have your answer by now. I really have to say that paying for Hyperlynx once is a lot cheaper than fixing board, after board, with bad SI. In fact one re-spin of the pcb is about what the tool costs. Now, you know I don't gain anything from the endorsement of this tool, unless it is one of our parts that is being used (as the board gets done sooner, and we see revenue earlier). Seems some companies really have forgotten that they need customers. Been a long time since I posted something like this... with Peter Alfke retired from Xilinx, I wear a "white hat" all the time now, and I am nothing but nice, and helpful (no negativity!). I think my fearsome reputation in the halls of the 'other' FPGA company has quietly faded from memory. AustinArticle: 145890
Hello, I am using Xilinx ISE 11.1, and I need to place some components in certain areas of the FPGA. I have never done manual PaR, so here are a few questions: 1) Do I need to manually place each and every net? 2) Is it possible to just place 'blocks' of each component in a general area of CLB on the device, and let the PaR algorithms auto route any connecting nets? Thanks in advance, JasonArticle: 145891
On Feb 27, 10:31=A0am, austin <aus...@xilinx.com> wrote: > Rick, > > Must not be a Xilinx part, as our hotline engineers have copies of all > popular signal integrity tools, and any webcase (from a paying > customer: =A0students and hobbyists might have to email me, or post > their queury on our forums) that provides the needed information (part > number, package, io type, drive strength, slew setting, pcb trace > length, load) can request a "what if" sanity check answer (slew rate, > overshoot, undershoot, SLOW/WEAK and FAST/STRONG IBIS process/voltage/ > temperature corners).... Decoding all that tho, confirms Rick's issue that there is no easy way for a customer to simply do this themselves ? Why is there no simple Spice pathway to allow users do the 'sanity check' stuff themselves ? It seems IBIS to spice is doable, but with some caveats, so is the sort of thing a vendor should do once, as opposed to hundreds of customers ? Many Spice offerings have node-limited freebies, and there are widely used free items like LTSpice and SpiceOpus. -jgArticle: 145892
Scott Lurndal wrote: > "(see below)" <yaldnif.w@blueyonder.co.uk> writes: >> On 24/02/2010 20:37, in article hm6fbd68gp@news6.newsguy.com, "Michael >> Wojcik" <mwojcik@newsguy.com> wrote: >> >>> (see below) wrote: >>>> Just the usual red tape: return address, frame pointer of caller; and either >>>> a static pointer or some housekeeping for 'display' registers (if used) to >>>> access non-locals. But bear in mind that in decent languages arrays are >>>> storable values, so a value array parameter gets copied in toto, unlike C. >>> It will be in C if the array is wrapped in a struct. Letting array >> That is passing a struct, not an array. >> >>> parameters decay to pointers was a feature of early C that couldn't be >>> changed for historical reasons, but when the standardization committee >>> added support for struct parameters, they made them first-class. >>> struct (and not the misnamed "typedef") is C's mechanism for creating >>> new types and ADTs, so if you want a pass-by-value array in C, the >>> correct thing to do is to put it in a struct. >> Yes. Preposterous, isn't it? > > Q? Why would anyone want to pass an array by value? > Because you can?Article: 145893
On Feb 26, 4:31 pm, austin <aus...@xilinx.com> wrote: > Rick, > > Must not be a Xilinx part, as our hotline engineers have copies of all > popular signal integrity tools, and any webcase (from a paying > customer: students and hobbyists might have to email me, or post > their queury on our forums) that provides the needed information (part > number, package, io type, drive strength, slew setting, pcb trace > length, load) can request a "what if" sanity check answer (slew rate, > overshoot, undershoot, SLOW/WEAK and FAST/STRONG IBIS process/voltage/ > temperature corners).... > > You know my email, too, so if you had emailed me, you would have your > answer by now. > > I really have to say that paying for Hyperlynx once is a lot cheaper > than fixing board, after board, with bad SI. In fact one re-spin of > the pcb is about what the tool costs. Now, you know I don't gain > anything from the endorsement of this tool, unless it is one of our > parts that is being used (as the board gets done sooner, and we see > revenue earlier). > > Seems some companies really have forgotten that they need customers. > > Been a long time since I posted something like this... with Peter > Alfke retired from Xilinx, I wear a "white hat" all the time now, and > I am nothing but nice, and helpful (no negativity!). I think my > fearsome reputation in the halls of the 'other' FPGA company has > quietly faded from memory. > > Austin Thanks for the reply. No, it isn't a Xilinx part and no one is respinning any boards over this. In fact, the point is that I have the ability to deal with the SI issue by adjusting the IO parameters. But it would be so much easier to get a handle on what settings to try for testing if I had the simple, basic data of what the part does when the settings are adjusted. I'm not planning to spend five large to make up for a vendor's shortcomings. If Xilinx had an appropriate part, I likely would have used it. But it is hard to find any FPGAs in 100 TQFP packages, much less Flash based ones. The problem started when we found the original setting produced a rising edge so slow that it created multiple pulses on a clock line. The board worked ok in the original chassis, but the new customer design uses a faster FPGA to receive the clock and had failures. In the end, I had to meet with my customer today with a bucket of boards with different settings. I think we can use one of the mid range values that gives a good trade off of edge rate and overshoot. I couldn't test one value because I made a mistake and programmed two boards with the same bit file. Unfortunately the missing one is likely the one we will want to use. So I'll be back with my customer Monday with another board. RickArticle: 145894
I have the Web Edition of Quartus and I can't seem to find how to generate a vector waveform file longer than 1000ns. Is it possible?Article: 145895
Giorgos Tzampanakis <gt67@hw.ac.uk> wrote in news:Xns9D2C232693681fdnbgui7uhu5h8hrnuio@127.0.0.1: > I have the Web Edition of Quartus and I can't seem to find > how to generate a vector waveform file longer than 1000ns. > Is it possible? Please ignore this, it's solved.Article: 145896
On Feb 27, 3:30=A0pm, rickman <gnu...@gmail.com> wrote: > =A0If Xilinx had an appropriate > part, I likely would have used it. =A0But it is hard to find any FPGAs > in 100 TQFP packages, much less Flash based ones. Which Flash FPGA in 100 pins did you select? Actel seem to have good coverage there, and we are about to trial a ProASIC nano. Actel also look to be releasing an ARM variant next week. -jgArticle: 145897
Michael Wojcik wrote: > glen herrmannsfeldt wrote: >> In comp.arch.fpga Charles Richmond <frizzle@tx.rr.com> wrote: >> (snip) >> >>> The dimensions of arrays *used* to have to be compile time >>> constants. Now they have a type of array declared in a function >>> that can have its size depend on an integer passed into the >>> function. (I forget what they call it... maybe a "dynamic array" >>> or something.) >> Yes, but can you do that for an array in a struct. > > No. The size of a struct type must be known at compile time, even in C99. > >> If you >> pass it in a function call, and it isn't the last argument, how >> will the called routine know where the other arguments are? > > If you *could* do this, that'd be an implementation issue, and outside > the scope of the C language. :-) > > (Technically, C says nothing about a stack. A conforming C > implementation could use activation frames that contain XML documents > describing each parameter in detail. It could use an indexed file to > implement the call stack. It could implement calls by generating > subprograms on the fly that get their parameters via pipes. If they > get there on the backs of unicorns ridden by nasal demons, that's OK > with the standard too.) > Sure the implementation is left up to the compiler writer. But however the arguments are passed and the functions called, the implementation is *equivalent* to using a stack... because it accomplishes the same thing. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+Article: 145898
Peter Flass wrote: > Scott Lurndal wrote: >> "(see below)" <yaldnif.w@blueyonder.co.uk> writes: >>> On 24/02/2010 20:37, in article hm6fbd68gp@news6.newsguy.com, "Michael >>> Wojcik" <mwojcik@newsguy.com> wrote: >>> >>>> (see below) wrote: >>>>> Just the usual red tape: return address, frame pointer of caller; >>>>> and either >>>>> a static pointer or some housekeeping for 'display' registers (if >>>>> used) to >>>>> access non-locals. But bear in mind that in decent languages arrays >>>>> are >>>>> storable values, so a value array parameter gets copied in toto, >>>>> unlike C. >>>> It will be in C if the array is wrapped in a struct. Letting array >>> That is passing a struct, not an array. >>> >>>> parameters decay to pointers was a feature of early C that couldn't be >>>> changed for historical reasons, but when the standardization committee >>>> added support for struct parameters, they made them first-class. >>>> struct (and not the misnamed "typedef") is C's mechanism for creating >>>> new types and ADTs, so if you want a pass-by-value array in C, the >>>> correct thing to do is to put it in a struct. >>> Yes. Preposterous, isn't it? >> >> Q? Why would anyone want to pass an array by value? >> > > Because you can? In C, you can *not*... :-) -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+Article: 145899
You can just use PlanAhead to constrain your logic to a specific area of the fpga, then just let p&r do its job. Jon --------------------------------------- Posted through http://www.FPGARelated.com
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