51–57 of 57 posts
Why not use a propeller or propeller 2? Similar benefits, cheaper, easier to code on.
Q for the community. FPGA seems to be used for three things: 1) Custom I/O or high performance interfaces that aren't widely standardized 2) Prototyping boards / processor cores 3) Blazing fast implementations of algorithms that are hard to run otherwise. Is that about right? If even close, (3) is very interesting to me for a variety of reasons. Is my understanding correct that this is a reasonable use of FPGAs and t…
Caveat on 3): The only real benefit of an FPGA for algorithms is when you're algorithm benefits from parallelization. There is nothing intrinsically faster in programmable logic. The point is that execution is truly concurrent, as long as you have space in the FPGA fabric, you can _almost_ do everything at the same time. I say this as someone who has done a fair share of FPGA projects, it is very difficult to make th…
It probably depends what you're comparing to.
Yeah, since FPGAs essentially implement combinatorial logic, and hard CPUs are also implemented in combinatorial logic, you gain no benefit from directly "porting" the hard CPU to the FPGA.
But, if your hard CPU is a microcontroller that can only process say 8 bits at a time, but you really want to process say 256 bits at a time, it might be more efficient to use an FPGA to build a soft CPU whose architecture better matches your problem. In that case, you should be able to do more work per clock cycle with the FPGA.
That's arguably "increased parallelization", but what I'm talking about applies to sequential algorithms.
Of course, in that case, maybe you chose the wrong microcontroller. Maybe a full CPU would be a better choice, or maybe there's a DSP that can be adapted to the specific use case.
it is very difficult to make the business case for an FPGA, if your problem can be solved with GPU programming on a COTS GPU
Sure, that makes a lot of sense at the high end. I'm thinking of problems more in the embedded space, where FPGAs might be a bit more attractive.
Earlier quoted context omitted.
Personally I think "programming" RTL is dead simple. It's so simple, in fact, that it's not even interesting. But I've been doing it forever so my perspective is skewed.
I think you are thinking of different types of tasks. A lot of RTL is brainless, but if you are actually trying to compute with it, it can get tough. A mediocre C++ programmer can write a (bad) hash table in C++ in a few hours. How fast can you give me one in Verilog?
This talk struck me as conflicting in a sort of have-your-cake-and-eat-it-too kind of way. The wrinkles part[1] summarizes a lot of what this individual is advocating. Paraphrasing (with equivalent liberal handwaving of details as the talk does): I want to write FPGA code like any other high-level programming language ( but quickly dismiss that the hard part of developing native HDL is in fact that it's fundamentally…
What constrains PMod to low-frequency applications with sloppy SI? What inherently limits the frequency? I have been dabbling in FPGA programming on a Xilinx Nexys A7. Through some PMod ports, I've managed to drive the shift registers on an LED matrix display at 20MHz. Is this considered high frequency? My oscilloscope shows that the signal is somewhat messy at this frequency. But the data sheet for the shift registe…
To your shift register question---which is the only one with enough detail to afford a quick answer---referencing JEDEC JESD8C.01 § 2.3 Table 2 as basis of comparison: yes wrt VILmax, and no wrt VIHmin...at face value, it doesn't comply with industry standard, but is nevertheless permissible by Pmod spec because, well, it's a shit spec by a sample size of 1 engineer's measure.
To your TinyFPGA question, I don't care to ponder the design considerations (or lack thereof) of arbitrary hobbyist dev boards in the wild. In the nicest way possible, it's a complete waste of my time, sorry.
Suffice it to say the spec's interconnect choice is the primary limiter, compounded by permissiveness in some aspects, poor specificity in others, and the general ease of abusing objective interoperability while still complying with normative language.
I leave it to the passerby as an exercise to consider the implications of the following notions in this context:
1. All real conductors exhibit certain parasitic properties which deviate from an ideal model; whose characteristics are largely a function of physical geometries, relevant material properties, and the signals that flow in/around them; and whose significance is almost entirely dependent on the application under consideration.
2. An arbitrary signal that satisfies the 3 Dirichlet conditions can be summarily expressed as the linear sum of its fundamental and harmonic sinusoidal components.
3. As a back-of-the-envelope measure, transmission line effects cannot be so easily neglected when, in a point-to-point system, the ratio of the distance that a signal must traverse to the wavelength of the propagating signal itself exceeds roughly 1%.
Earlier quoted context omitted.
What constrains PMod to low-frequency applications with sloppy SI? What inherently limits the frequency? I have been dabbling in FPGA programming on a Xilinx Nexys A7. Through some PMod ports, I've managed to drive the shift registers on an LED matrix display at 20MHz. Is this considered high frequency? My oscilloscope shows that the signal is somewhat messy at this frequency. But the data sheet for the shift registe…
Not trying to be unhelpful, but if the assertion was not immediately evident, then you're missing a huge chunk of basic undergrad EE theory that cannot be dismissed as merely academic. I'd recommend reading the spec (it's only 10 pages) and coming to your own conclusions. To your shift register question---which is the only one with enough detail to afford a quick answer---referencing JEDEC JESD8C.01 § 2.3 Table 2 as…
To say that PMod's primary limiting factor is its interconnect choice is not very specific. The spec itself says that "speeds greater than 100MHz should be achievable using high-speed ports", so the claim that PMod is "inherently constrained to low-frequency applications" seems at best incomplete. I'm not arguing that every PMod port will support that -- obviously most are not designed for this -- but I am not seeing a fundamental limitation.
Earlier quoted context omitted.
Not trying to be unhelpful, but if the assertion was not immediately evident, then you're missing a huge chunk of basic undergrad EE theory that cannot be dismissed as merely academic. I'd recommend reading the spec (it's only 10 pages) and coming to your own conclusions. To your shift register question---which is the only one with enough detail to afford a quick answer---referencing JEDEC JESD8C.01 § 2.3 Table 2 as…
Yep, I'm undoubtedly missing a huge chunk of basic undergrad EE theory, seeing as I am a CS guy, not EE. That said, I think it's possible (even fun) to explain key concepts to people outside your own field in plain language. I practice on my friends and girlfriend a lot. To say that PMod's primary limiting factor is its interconnect choice is not very specific. The spec itself says that "speeds greater than 100MHz sh…
If you insist on settling on an answer constrained to classical 1st-order models, then you're in for a treat: everything should just work! The guzzintos perfectly match the guzzoutas, first law of thermodynamics is demonstrably preserved, motherhood and apple pie, happy endings.
Except that's not how the real world works...and it almost certainly won't meet any pragmatic definition of commercially reliable at the limits you're wanting to probe at. But why trust what I have to say? You have an entirely capable Artix-7 dev board at your beck and call. And you have an oscope that'll generate eye diagrams all day to your heart's content. And the Pmod interconnect is so trivial that you could even hack together a throwaway DUT load...or why bother with that when you could use one of your existing Pmods as a real world DUT to characterize?
I thought I left enough breadcrumbs for the incidental reader to self-service on how deep down this infinite rabbit hole will be sufficient to grasp the magnitude of the questions being asked, and I thought my language was appropriately tailored. Maybe not. Here's a few more courtesy hints:
1. The first remark was to steer towards qualitatively thinking about the role of parasitic inductance and how this parameter will dominate the interconnect at higher frequencies as skin effect kicks on. It's worth noting that you'll be quickly sucking hind tit attempting to control impedance through a board-to-board interconnect of this design, which immediately kills reasonable prospects for a huge chunk of the application space that FPGAs are chosen as a viable host for right out of the gate!
2. The second remark was to kindly say that EEs who care about SI couldn't care less about the fundamental frequency of your digital signal when what matters in practice are the significant harmonics that said signal's edges are comprised of. The term significant here is roughly defined as at least 10%ish of the fundamental's magnitude. To get a feel for the landscape, derive the Fourier series expansion of (keeping things simple) an ideal square wave and interpretation of the rest should naturally follow.
3. The third remark was to establish a ballpark basis for independently sizing up when the convenience of simple 1st-order models start to break down and it becomes necessary as a matter of due diligence to kick it up a notch. Determine the permissible distance your signal needs to travel. Determine the wavelength of the highest significant harmonic of the signal to account for (assume in a vacuum to keep it simple, completely ignoring substrate permittivity). If the ratio of distance to wavelength exceeds 1%, consult with a competent electronics engineer if you objectively care about quality.
That's about the best approximate free answer this engineer is willing to extend. Need better precision? I'd recommend deferring to a billable scientist.
(P.S. only about as fun as trying to explain the merits of idempotency to my wife /s)
Earlier quoted context omitted.
Yep, I'm undoubtedly missing a huge chunk of basic undergrad EE theory, seeing as I am a CS guy, not EE. That said, I think it's possible (even fun) to explain key concepts to people outside your own field in plain language. I practice on my friends and girlfriend a lot. To say that PMod's primary limiting factor is its interconnect choice is not very specific. The spec itself says that "speeds greater than 100MHz sh…
You're probing for an easy answer because you think one exists that'll be as easy as handling the commodity 100mil interconnect you've been playing with. But the fact is a minimal satisfactory answer resides in the 2nd level of nature's bowels where the simple conservative models of Ohm's law and the laws of Kirchhoff that you were taught in basic physics start to break down as a useful standalone tool and must be su…
One of the following must be true:
1. The PMod interconnect is specified in a way that inherently limits high frequency applications, whereas it could have been specified in a different way that would allow for them.
2. Something about the design space PMod is trying to solve (off-board peripheral modules connected to a main board through a standard connector) is inherently hostile to high-frequency applications, and no specification is capable of getting around this limitation.
3. PMod is actually capable of high-frequency applications, although most PMod ports are not particularly designed for this.
Your original message seemed to be claiming (1), but none of your subsequent arguments have offered any support for (1) that I can see. You have absolutely convinced me that complex physical effects must be taken into account, but that information does not help resolve which of 1-3 is true.
To convince me of (1) I would need to see a specific design decision in the PMod spec that makes high-frequency applications impossible, as well as the alternative design choice that would have allowed for them. For example: "PMod does not allow shielded wires, but high-frequency requires shielding" would be a convincing argument if true.