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
I've just noticed and read the thread you started just before Christmas about your Fifo problem. You said... > problem fixed! > solution and explanation in the next Brain issue > (I will post short post also after the issue release) Any sign of the new Brain? BTW, was the read indicated by a single clock width pulse that was always de-asserted after each read, or could this have been active for a number of 62.5mhz cycles? I'd have changed the design so the internal read flag was inverted at each read, then the number of reads couldn't have been mistaken by the higher speed clock domain. Looking forward to the solution.. NialArticle: 145976
JuNNi wrote:
> Hi, I am a beginner at FPGA. I had a query that which platform is used for
> professional digital designs. Is it linux or windows??
Linux of course. And, if I might add, using vi and make.
OK, the "of course" applies only to me, but I didn't want
to switch to Windows to do FPGA development so I took the
time to figure out what ISE was doing under the covers and
found that all the real work is done by programs that can
be invoked at the command line. Eventually I was able to
even build a makefile for my project.
I wrote an article for Nuts & Volts magazine describing how
to use command line tools and makefiles for FPGA development.
The article is at
http://www.demandperipherals.com/docs/CmdLineFPGA.pdf
I had a little trouble getting the proprietary JTAG drivers
to work under Linux, so when I designed my board (Baseboard4)
I made it so you could download the FPGA code to a USB-serial
port using just a 'cat' command.
It turns out that the command line approach works as well
under Windows as it does under Linux, if that is of any use
to you.
thanks
Bob Smith
Article: 145977"(see below)" <yaldnif.w@blueyonder.co.uk> writes: > On 24/02/2010 23:55, in article > 1bmxyy42ag.fsf@snowball.wb.pfeifferfamily.net, "Joe Pfeiffer" > <pfeiffer@cs.nmsu.edu> wrote: > >> When I was an undergrad I spent some time programming FORTRAN on a >> Harris /6 (I think it was a /6 -- there's something nagging at the back >> of my mind that says it may have been a /7). Anyway, reading the manual >> I discovered that return addresses were stacked, and immediately jumped to >> the conclusion that it could do recursion. It turned out that local >> variables were static... which meant I spent a *long* time figuring out >> why my program was producing completely nonsensical results. >> >> As Al Stewart once sang, "I was jumping to conclusions, and one of them >> jumped back." > > People who assumed that FORTRAN local variables *must* be static got jumped > on from the opposite direction when they used FORTRAN compilers that > actually did put them on the stack, as the ANS FORTRAN standard was > carefully worded to permit. All these decades I thought that was the case.... of course, I only programmed FORTRAN for a couple of years around 1980. -- 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: 145978
JuNNi wrote:
> Hi, I am a beginner at FPGA. I had a query that which platform is used for
> professional digital designs. Is it linux or windows??
Linux of course. And, if I might add, using vi and make.
OK, the "of course" applies only to me, but I didn't want
to switch to Windows to do FPGA development so I took the
time to figure out what ISE was doing under the covers and
found that all the real work is done by programs that can
be invoked at the command line. Eventually I was able to
even build a makefile for my project.
I wrote an article for Nuts & Volts magazine describing how
to use command line tools and makefiles for FPGA development.
The article is at
http://www.demandperipherals.com/docs/CmdLineFPGA.pdf
I had a little trouble getting the proprietary JTAG drivers
to work under Linux, so when I designed my board (Baseboard4)
I made it so you could download the FPGA code to a USB-serial
port using just a 'cat' command.
It turns out that the command line approach works as well
under Windows as it does under Linux, if that is of any use
to you.
thanks
Bob Smith
Article: 145979All, Yes, Tabula is in the sunshine of the vulture capital technology rollout phase. I like the FPGA Journal's characterization of the technology announcements: been there, done that, and when you ship the parts, let me know. However, it is a necessary part of doing business that you attempt to generate excitement for a new product. I will suggest to you that you go back and read all the hype, up until now, as it does tell a better story of what is going on. For example, originally, the technology was better in cost, speed, and power (how they got their funding). Then, after awhile, cost, maybe speed (in some applications), and power. In the latest release, we see cost, maybe speed, and power will be the same or worse. "There ain't no such thing as a free lunch" (TANSTAAFL), and if you can context switch at 1.6 GHz, with 8 time slices, then you have a 200 MHz fabric which is somewhat smaller (not 8, but perhaps 6?) than a comparable run of the mill FPGA device. With the added dynamic power (CV^2F), since the capacitance of the interconnect is based on its length, and their claim is that the length of interconnect in their devices is 1/5th that of a comparable device, we can suppose that C is 1/5th. Given that they ALWAYS switch at 1.6 GHz some nodes, and they have announced that power is not one of the benefits any longer, we can pretty much conclude that because of the time slicing, the improvement in interconnect didn't pan out and result in a cost savings, but came in as a wash, or perhaps worse. In order to operate at 1.6 GHz, they have to have all the transistors be really fast, which means really leaky, so perhaps their static power is out of control, as well. In a comparable 'old style' FPGA device, many transistors may be lower leakage, as they don't switch that fast. Of course, we may have 5 times as many devices as the Tabula chip, but they may have 10 times less leakage. Is there a targeted market? You bet, they have aimed at the "networking high end" which is the bread and butter of the big players! Will they actually meet the requirements? What is the reliability? What is their soft error behavior? What happens when the design doesn't work: how do you debug the "magic" they perform by re-interpreting your HDL code? It will be interesting: is this just an excuse to buy really nice cars, and get fat paychecks, until it all blows up? Or, is this a novel, and game-changing technology? Having been part of the SIlicon Valley community since 1978, this is a very familiar tune, and how it plays out may not be such a surprise to anyone (except the investors). I have to say, they have a stellar group of people, ex-Xilinx, and ex- Altera both. AustinArticle: 145980
On Mar 2, 1:39=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Mon, 1 Mar 2010 17:28:38 -0800 (PST), fpgabuilder wrote: > >I need to instantiate LVDS interfaces in my top-level. =A0I am planning > >to use SV interface blocks. =A0Altera's documentation suggests that LVDS > >i/os should only be instantiated using a megafunction. =A0But the > >interface blocks do not allow hierarchy so I cannot instantiate a > >megafunction inside the interface block. > > >Any thoughts on this? > > This sounds to me like an inappropriate use of SV interfaces. > When you say "I am planning to use SV interface blocks", what > exactly do you intend? =A0Interfaces are useful in certain > situations, but you definitely would not want to use them > everywhere in your design. =A0In particular, you should avoid > using interfaces for the design's top-level I/O because it > will inevitably cause trouble with other tools in the flow. > > It is not quite true that "interfaces do not allow hierarchy". > You cannot create a *module* instance inside an interface, > but you certainly can have an *interface* instance inside > another. =A0However, nested interface instances are not > necessarily synthesizable. > -- > Jonathan Bromley Interesting. That is exactly what I was intending to do i.e. use interfaces in my top-level i/os. What kind of tool issues you think this will cause? I am still new to interfaces and system verilog in general and was going through Sutherland, et. all's book SystemVerilog for Design. We only use two tools in our environment... Quartus and Modelsim DE. Quartus's documentation says it supports interfaces... not sure if it supports hierarchy but I was going to try that as well. In our environment where we do not have separate verification and design teams most of the engineers prefer reuse across synthesizable code and verification test benches. Therefore, it seems like use of interfaces in top-level i/o is a good idea albeit if the tool supports it which brings back to the point you raised.Article: 145981
rickman wrote: > On Mar 2, 5:14 am, digitaljanitor <b7grabn...@sneakemail.com> wrote: >> All, >> >> Apologies for the cross-post, I know a lot of people who deal with >> FPGAs are also experts with PCBs, stack-ups, high-speed layout, hoping >> for some good ideas from both groups. I'm not an expert on board >> design or electronics, but I'm trying to do things right from the >> start... >> >> My issue in a nut shell: How can I properly prevent ground-loops from >> external connections that interface to my board? I receive several >> digital signals streams from two to four external boards, single- >> ended, ~5 Mbps, almost zero-balanced. My board has sensitive analog >> and audio/video and I'd like to avoid the possibility of ground-loops, >> 60 Hz hum, etc. >> >> I know of three methods to isolate and I list the methods and my >> thoughts. >> >> 1. I can use a capacitor in-series with each input signal and level- >> shift it back so my digital ICs will properly trigger and keep the >> ext_GND isolated from my sys_GND. I have tested this and it's >> reliable for my configuration. >> >> But! I'm very worried about EMI and return currents. If I use a >> capacitor to couple the external signal in AND I don't connect >> ext_GND(s) to my sys_GND, I fear that the return current from the >> input signal will see an impedance discontinuity and cause me MORE EMI >> headaches. I reason that the current should flow in a loop and while >> the capacitor isolates my two systems, the return current will still >> have to go back to the original source and since my GNDs are >> discontiguous, I have a high-impedance return (maybe through free >> space) and this will couple more noise into my system. >> >> 2. I can use an isolation transformer (1:1) and a capacitor on the >> input side to avoid saturating the core (strip DC) and use a cap on >> the output & restore the DC. >> >> I wonder if the capacitance between windings, other parasitics and EM >> "leakage" however won't end up defeating the purpose of isolation and >> will end up coupling noise from the external circuits into my system. >> Since my signals are single-ended I don't have a differential receiver >> to reject the common-mode noise either. >> >> I'm also uncertain if the return current has a path, but based on my >> recollection of transformers, the load impedance is reflected back to >> the source, so there is a "path" and both sides are coupled together. >> >> 3. I can use a digital isolator (NVE, ADI) and have it straddle the >> external input block and my digital system. >> >> The issue here is the need for power on the external input side that >> would have to be isolated from the digital side. I also wonder, since >> the NVE/ADI parts end up using magnetic isolation techniques, will >> they end up broadcasting any EM? >> >> Thank you! >> Sam. > > I guess my first question is to figure out if any of this is > overkill. When you say you have signals coming from "external" > boards, do you mean a separate chassis? If the boards are in the same > case, then proper grounding techniques should do the job. Not necessarily, depending on the noise sensitivity of the sensitive bits and the level of noise elsewhere. Great Big Ground Planes significantly reduce ground loop effects, but they don't eliminate them. > If you are sure that you need this sort of isolation there is a third > choice, optical isolation. 5 Mbps is not beyond the speed of > optoisolators. A quick search turns up parts rated up to 50 Mbps. > The input devices require no special circuitry and output devices > simply require a power supply that is separate and isolated since this > becomes the only path for conducted noise. > > I guess my real concern is that if you are so worried about the return > current and coupled EMI from the external digital signals, why don't > you put the digital electronics on a separate card? That is the best > way to provide proper isolation from the digital noise... at least the > best first step. If it can be done, indeed. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 145982
digitaljanitor wrote: > All, > > Apologies for the cross-post, I know a lot of people who deal with > FPGAs are also experts with PCBs, stack-ups, high-speed layout, hoping > for some good ideas from both groups. I'm not an expert on board > design or electronics, but I'm trying to do things right from the > start... > > My issue in a nut shell: How can I properly prevent ground-loops from > external connections that interface to my board? I receive several > digital signals streams from two to four external boards, single- > ended, ~5 Mbps, almost zero-balanced. My board has sensitive analog > and audio/video and I'd like to avoid the possibility of ground-loops, > 60 Hz hum, etc. > > I know of three methods to isolate and I list the methods and my > thoughts. > > 1. I can use a capacitor in-series with each input signal and level- > shift it back so my digital ICs will properly trigger and keep the > ext_GND isolated from my sys_GND. I have tested this and it's > reliable for my configuration. > -- snip -- Caps will block DC ground noise, but will let the high frequency ground noise come sailing through unimpeded. > 2. I can use an isolation transformer (1:1) and a capacitor on the > input side to avoid saturating the core (strip DC) and use a cap on > the output & restore the DC. > > I wonder if the capacitance between windings, other parasitics and EM > "leakage" however won't end up defeating the purpose of isolation and > will end up coupling noise from the external circuits into my system. > Since my signals are single-ended I don't have a differential receiver > to reject the common-mode noise either. An ideal transformer won't provide a noise path into your board. Your goal in using a transformer would be to understand just how much coupling you can stand, and see if you can find a transformer that stays below that threshold. > I'm also uncertain if the return current has a path, but based on my > recollection of transformers, the load impedance is reflected back to > the source, so there is a "path" and both sides are coupled together. The signal return path would be through that signal's local ground. > 3. I can use a digital isolator (NVE, ADI) and have it straddle the > external input block and my digital system. > > The issue here is the need for power on the external input side that > would have to be isolated from the digital side. I also wonder, since > the NVE/ADI parts end up using magnetic isolation techniques, will > they end up broadcasting any EM? I doubt that a digital isolator would add much EMI. Yes, you'd need to power up your analog, but that could be done with a little switching supply that's transformer coupled. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 145983
digitaljanitor wrote: > All, > > Apologies for the cross-post, I know a lot of people who deal with > FPGAs are also experts with PCBs, stack-ups, high-speed layout, hoping > for some good ideas from both groups. I'm not an expert on board > design or electronics, but I'm trying to do things right from the > start... > > My issue in a nut shell: How can I properly prevent ground-loops from > external connections that interface to my board? I receive several > digital signals streams from two to four external boards, single- > ended, ~5 Mbps, almost zero-balanced. My board has sensitive analog > and audio/video and I'd like to avoid the possibility of ground-loops, > 60 Hz hum, etc. > > I know of three methods to isolate and I list the methods and my > thoughts. > > 1. I can use a capacitor in-series with each input signal and level- > shift it back so my digital ICs will properly trigger and keep the > ext_GND isolated from my sys_GND. I have tested this and it's > reliable for my configuration. > > But! I'm very worried about EMI and return currents. If I use a > capacitor to couple the external signal in AND I don't connect > ext_GND(s) to my sys_GND, I fear that the return current from the > input signal will see an impedance discontinuity and cause me MORE EMI > headaches. I reason that the current should flow in a loop and while > the capacitor isolates my two systems, the return current will still > have to go back to the original source and since my GNDs are > discontiguous, I have a high-impedance return (maybe through free > space) and this will couple more noise into my system. > Capacitive coupling doesn't do much for you here, it doesn't cut the return path. You could run them through common mode chokes but with too many lines that can get old. > 2. I can use an isolation transformer (1:1) and a capacitor on the > input side to avoid saturating the core (strip DC) and use a cap on > the output & restore the DC. > > I wonder if the capacitance between windings, other parasitics and EM > "leakage" however won't end up defeating the purpose of isolation and > will end up coupling noise from the external circuits into my system. > Since my signals are single-ended I don't have a differential receiver > to reject the common-mode noise either. > With a transformer your signal isn't single-ended anymore. <scratching head> > I'm also uncertain if the return current has a path, but based on my > recollection of transformers, the load impedance is reflected back to > the source, so there is a "path" and both sides are coupled together. > A good transformer will send nearly all common mode noise and ground-conducted stuff out to pasture, it's usually the way to go. The challenge is to find one that's good, cheap and most of all available. LAN transformers could be great candidates. You can get them in 2-packs, 4-packs and even with extra common mode chokes integrated. > 3. I can use a digital isolator (NVE, ADI) and have it straddle the > external input block and my digital system. > > The issue here is the need for power on the external input side that > would have to be isolated from the digital side. I also wonder, since > the NVE/ADI parts end up using magnetic isolation techniques, will > they end up broadcasting any EM? > If you have enough amplitude optocouplers are also an option and you don't have to worry about any DC restoration. One of my favorites for faster stuff is the CNW137 but that's because I work in hi-rel and medical and they come in gullwing wide body: http://www.avagotech.com/docs/AV02-0940EN -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 145984
digitaljanitor wrote:
> All,
>
> Apologies for the cross-post, I know a lot of people who deal with
> FPGAs are also experts with PCBs, stack-ups, high-speed layout, hoping
> for some good ideas from both groups. I'm not an expert on board
> design or electronics, but I'm trying to do things right from the
> start...
>
> My issue in a nut shell: How can I properly prevent ground-loops from
> external connections that interface to my board? I receive several
> digital signals streams from two to four external boards, single-
> ended, ~5 Mbps, almost zero-balanced. My board has sensitive analog
> and audio/video and I'd like to avoid the possibility of ground-loops,
> 60 Hz hum, etc.
>
> I know of three methods to isolate and I list the methods and my
> thoughts.
>
> 1. I can use a capacitor in-series with each input signal and level-
> shift it back so my digital ICs will properly trigger and keep the
> ext_GND isolated from my sys_GND. I have tested this and it's
> reliable for my configuration.
>
> But! I'm very worried about EMI and return currents. If I use a
> capacitor to couple the external signal in AND I don't connect
> ext_GND(s) to my sys_GND, I fear that the return current from the
> input signal will see an impedance discontinuity and cause me MORE EMI
> headaches. I reason that the current should flow in a loop and while
> the capacitor isolates my two systems, the return current will still
> have to go back to the original source and since my GNDs are
> discontiguous, I have a high-impedance return (maybe through free
> space) and this will couple more noise into my system.
>
> 2. I can use an isolation transformer (1:1) and a capacitor on the
> input side to avoid saturating the core (strip DC) and use a cap on
> the output & restore the DC.
>
> I wonder if the capacitance between windings, other parasitics and EM
> "leakage" however won't end up defeating the purpose of isolation and
> will end up coupling noise from the external circuits into my system.
> Since my signals are single-ended I don't have a differential receiver
> to reject the common-mode noise either.
>
> I'm also uncertain if the return current has a path, but based on my
> recollection of transformers, the load impedance is reflected back to
> the source, so there is a "path" and both sides are coupled together.
>
> 3. I can use a digital isolator (NVE, ADI) and have it straddle the
> external input block and my digital system.
>
> The issue here is the need for power on the external input side that
> would have to be isolated from the digital side. I also wonder, since
> the NVE/ADI parts end up using magnetic isolation techniques, will
> they end up broadcasting any EM?
>
> Thank you!
> Sam.
A good way to do this if you have control of all the spigots is to use
differential signaling (RS-422 would be adequate at 5MHz), and don't
connect the signal ground to the board ground. That way everything
stays referenced to the same ground, but you're not providing any low
impedance ground paths to your board's signal ports. You can't do this,
but you can try to get the same effect.
You say your signal is "almost zero biased" -- what do you mean? Do you
mean that it has just about as many ones as zeros? Can you count on
this, or do you sometimes have long stretches of zeros or ones? How long?
At any rate, you should be able to feed your signal into a high speed
comparator or line receiver, with a suitable local reference for your
signal's 'midway' point:
VCC
+
___ |
.--|___|--'
|
| |\
o------|-\ sig out
| | >----------o
sig in o----------)------|+/
| |/
|| |
o-----||---o
sig return || |
.-.
| |
| |
'-'
|
|
===
GND
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
This circuit assumes that your grounds are well referenced at DC, and
that you can stand some high-impedance coupling. It couples any
high-speed ground bounce to the comparator input to keep your noise
margins up, but it somewhat isolates your board's ground from the rest
of the system ground.
Depending on what you have, the comparator can me a regular high-speed
comparator, or something like an RS-485 receiver (terminate to the
signal return, _not_ to the board ground!), or other suitable line
receiver. Just read the specifications carefully, 'cause you'll be
'misusing' just about anything called a 'line receiver' -- you want to
make sure that you're maintaining isolation and providing the receiver
with enough margins.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Article: 145985glen herrmannsfeldt wrote: > 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.) It's been too long since I used Fortran (or FORTRAN, of whatever vintage) in anger to speculate on the subject. The main thing I remember about Fortran arrays is that they're in column-major order, so when I worked on Fortran bindings for graphics libraries written in C, I had to transpose the arrays. (This was when I worked on the X11 implementations of GKS and PEX at IBM.) -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145986
Ahem A Rivet's Shot wrote: > On Fri, 26 Feb 2010 13:48:48 -0500 > Michael Wojcik <mwojcik@newsguy.com> wrote: > >> 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. > > This is saying the same thing as I did in different terms and with > greater detail. I supposed, if you want to gloss "doesn't really implement an array type" as "does implement an array type". That seems rather a stretch to me. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145987
Charles Richmond wrote: > Michael Wojcik wrote: >> >> (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. Yes, yes, obviously. I must remember henceforth to add a standard disclaimer to any similar posts. The point still stands: C says nothing about a stack, and that includes nothing about a contiguous stack with no metadata. An implementation is free to provide a stack-equivalent that describes the activation in glorious detail, and so accommodates all sorts of things that are difficult to implement with a dumb stack. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145988
Joe Pfeiffer wrote: > 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! It's the moral equivalent of the OO idiom where a temporary object is created from a parameter via copy constructor, then discarded and eventually reclaimed by garbage collection. IME, that's quite common in a lot of OO applications (in OO languages with garbage collection, of course). Whether it's a Good Thing is highly contextual and largely subjective, of course. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145989
Scott Lurndal wrote: > 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? > > Perhaps stupid was a bit strong. As an OS designer/implementer, I > find the copy to be a problem; perhaps for other applications, it > would make some sense (although most the apps I can think of that > process arrays are probably better off in FORTRAN or R or Mathematica. I'll agree that when I write C code (which until recently was most of the time; these days I happen to be writing mostly OO COBOL, ECMAScript, and occasionally PHP and Ruby), I like to keep a close watch on memory consumption - partly because I'm likely writing system code that needs to be conservative, and partly because C encourages that mindset. This is particularly true with automatic allocation and multithreaded programs. I've had to correct far too many thread-stack-overflow bugs (pretty much always in someone else's code) because of auto-class variable abuse. >>> 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? > > Yes, a point. However, I'd be concerned about the adverse affect on > performance if used for subtantially large arrays. Yes. You'd want to restrict this to quite small objects, I think. In general, explicit allocation of copies from the heap is the better idea in C programs, because it gives you much better error handling. There's no standard mechanism for dealing with hitting the stack limit, and even the extensions offered by various implementations don't help much. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145990
Peter Flass wrote: > > Hey! C's finally caught up to PL/I. Only took them 50 years, and then > of course all the features are just tacked-on in true C fashion, instead > of thought-through. Well, that's rather insulting to the members of WG14, who spent a decade designing those features. Fortunately, they published the Rationale showing that, in fact, they were thought through.[1] And a great deal of documentation describing the process is available in the archives.[2] If you'd care to show why you think otherwise, perhaps there would be some grounds for debate. [1] http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf [2] http://www.open-std.org/JTC1/SC22/WG14/www/documents.html -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State UniversityArticle: 145991
On Mar 3, 2:07=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 2, 1:08=A0am, -jg <jim.granvi...@gmail.com> > > A small notch appe= ars, on the driving end ;) > > > Which end were you probing, your end, or connector, or the customers > > FPGA pin ? > > > -jg > > The driver. =A0Does it show up at the same time for both 8 and 12 mA > drive? That would be by varying the slew rate in the PWL source, and yes, it comes and goes as the slew rate hits a critical threshold. Spice says the waveform at the receive end does not have that notch. -jgArticle: 145992
On Mar 2, 8:39=A0am, austin <aus...@xilinx.com> wrote: > Is there a targeted market? =A0You bet, they have aimed at the > "networking high end" which is the bread and butter of the big > players! Reminds me of some of the players that tried to compete with Intel on high-end x86 processors. Only AMD has been successful at that. Your technical advantages will no longer be advantages by the time you get the product to market. A friend was an engineer at one of the companies that tried it back in the late 486 era. He called that business plan "running ahead of the steamroller". The steamroller doesn't seem to move that fast, so you can run ahead of it for a while, but you get tired before the steamroller does.Article: 145993
On Tue, 2 Mar 2010 11:28:02 -0800 (PST), Eric Smith wrote: >The steamroller doesn't seem to move that fast, so you >can run ahead of it for a while, but you get tired before the >steamroller does. Nicely put, but that way lies stagnation and the ultimate death of our industry. Sometimes there will be a truly novel, industry-regenerating idea out there. No-one can reliably guess which one of the ideas will be that mould-breaker, but it is important to stay aware of the possibilities. There are domains where there appears to have been continuous steady improvement - semiconductor wafer size getting bigger, design rules getting smaller, hard disk capacity getting bigger and cheaper - but those progressive improvements are not truly progressive; they are fuelled by discontinuous changes (the discovery and exploitation of GMR-effect in disk drives, for example). You don't immediately see a huge stepwise change because of these innovations; there's no point in creating something that's 10 times as good as the competition, when something 1.5 times as good will make you rich. So it appears to the casual or ill-informed observer that things just go on getting better without innovation, when in truth it is innovation (and the pull of consumer demand) that drives it all. Good luck to Tabula. They must play the game by the rules, and they are up against unfair odds - just count the number of FPGA vendors, many of them genuinely innovative, who have fallen by the wayside. But they just might be on to something. And, as Austin concludes, they have a dream team. They won't beat Xilinx at their own game, but they just might be writing the rules of a completely new game. -- Jonathan BromleyArticle: 145994
On 2 Mar, 11:22, Symon <symon_bre...@hotmail.com> wrote: > This lot seems to be revealing a bit more about their stuff. > > http://www.mercurynews.com/breaking-news/ci_14493616 > > http://www.tabula.com Looks interesting. Increasing transistor speed with lower power is advancing, but reducing interconnect R and C seems to be at a limit of copper thickness. The copper can be thickened up to limits. The flop 4LUT mux thing with is a 7LUT * 8 with simple time rotary mux may be. Then it's just lower interconnect density and length. Umm have to wait and see. cheers Jacko http://forum.nibzx.co.uk - general technical forumArticle: 145995
On Mar 3, 12:22=A0am, Symon <symon_bre...@hotmail.com> wrote: > This lot seems to be revealing a bit more about their stuff. > > http://www.mercurynews.com/breaking-news/ci_14493616 > > http://www.tabula.com Time will tell.... meanwhile, over in the other corners, anyone remember Triscend ? Well, others are having a crack at the same market, but slightly updated, for 2010. See Cypress PSoC5 (Data, no open samples yet) and the just unveiled Actel A2F200 (supposedly real silicon & Eval) These both bundle a FLASH Cortex uC with Analog and FPGA fabric. Sounds great on a marketing-lunch-napkin, but the fish-hook in this has always been price, and the conflict of constrain of Flash.Ram.cells. The sampling smaller sibling, the PSoC3 has moved to ~$20 in price indicators, and the A2F200 is showing ~$40 (no indications yet of the A2F060) You can get a choice of ARM core, for $1-$3, and a choice of CPLD- FPGA for $3-$6, so that single-package-premium really narrows down the customers. -jgArticle: 145996
Hi folks, we just published the winter issue of Xcell Journal: http://www.xilinx.com/publications/xcellonline/index.htm. This one has a lot of great how-to content including part 1 of a piece on How to Achieve Timing Closure on FPGAs, tutorials on adding the MicroBlaze to your design and Implementing Downsampling FIR Filters in Xilinx FPGAs. It also has a couple cool methodology pieces. And I interviewed some folks in the know to write a cover story on the FPGA play in the rapidly progressing broadcast equipment market. The pace of innovation in that market, especially over the last few years, is quite remarkable. I hope you find it useful and informative. Cheers, Mike Santarini publisher/editor, Xilinx Xcell JournalArticle: 145997
On Tue, 02 Mar 2010 13:24:00 -0500 Michael Wojcik <mwojcik@newsguy.com> wrote: > Ahem A Rivet's Shot wrote: > > On Fri, 26 Feb 2010 13:48:48 -0500 > > Michael Wojcik <mwojcik@newsguy.com> wrote: > > > >> 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. > > > > This is saying the same thing as I did in different terms and > > with greater detail. > > I supposed, if you want to gloss "doesn't really implement an array > type" as "does implement an array type". That seems rather a stretch > to me. That "first-class" bit is the "really". -- 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: 145998
Joe Pfeiffer wrote: > "(see below)" <yaldnif.w@blueyonder.co.uk> writes: > >> On 24/02/2010 23:55, in article >> 1bmxyy42ag.fsf@snowball.wb.pfeifferfamily.net, "Joe Pfeiffer" >> <pfeiffer@cs.nmsu.edu> wrote: >> >>> When I was an undergrad I spent some time programming FORTRAN on a >>> Harris /6 (I think it was a /6 -- there's something nagging at the back >>> of my mind that says it may have been a /7). Anyway, reading the manual >>> I discovered that return addresses were stacked, and immediately jumped to >>> the conclusion that it could do recursion. It turned out that local >>> variables were static... which meant I spent a *long* time figuring out >>> why my program was producing completely nonsensical results. >>> >>> As Al Stewart once sang, "I was jumping to conclusions, and one of them >>> jumped back." >> People who assumed that FORTRAN local variables *must* be static got jumped >> on from the opposite direction when they used FORTRAN compilers that >> actually did put them on the stack, as the ANS FORTRAN standard was >> carefully worded to permit. > > All these decades I thought that was the case.... of course, I only > programmed FORTRAN for a couple of years around 1980. With the older FORTRAN's, you have to "know your implementation". Tricks were used especially to handle ASCII data in numeric variables in the early days. -- +----------------------------------------+ | Charles and Francis Richmond | | | | plano dot net at aquaporin4 dot com | +----------------------------------------+Article: 145999
Michael Wojcik wrote: > Peter Flass wrote: >> Hey! C's finally caught up to PL/I. Only took them 50 years, and then >> of course all the features are just tacked-on in true C fashion, instead >> of thought-through. > > Well, that's rather insulting to the members of WG14, who spent a > decade designing those features. Fortunately, they published the > Rationale showing that, in fact, they were thought through.[1] And a > great deal of documentation describing the process is available in the > archives.[2] > > If you'd care to show why you think otherwise, perhaps there would be > some grounds for debate. "The flexible array must be last"? "sizeof applied to the structure ignores the array but counts any padding before it"? C is a collection of ad-hoc ideas. WG14 may have put a great deal of thought into how to extend it without breaking the existing mosh, but that's my point, it's still a mosh.
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