On Mon, 23 May 2016 15:00:29 -0400, rickman wrote:
> On 5/23/2016 2:02 PM, Tim Wescott wrote:
>> On Mon, 23 May 2016 13:18:24 -0400, rickman wrote:
>>
>>> On 5/23/2016 2:44 AM, Tim Wescott wrote:
>>>> On Sun, 22 May 2016 06:37:31 -0400, rickman wrote:
>>>>
>>>>> On 5/22/2016 1:32 AM, Tim Wescott wrote:
>>>>>> On Sat, 21 May 2016 23:32:59 -0400, rickman wrote:
>>>>>>
>>>>>>> On 5/21/2016 1:43 PM, Tim Wescott wrote:
>>>>>>>>
>>>>>>>> I should mention -- for the most part I'm not an FPGA guy. I'm
>>>>>>>> circuit design and software, with enough FPGA chops to do simple
>>>>>>>> stuff. I have done FPGA projects that have left the customer
>>>>>>>> happy,
>>>>>>>> but I've done more work that involves credibly _threatening_ (one
>>>>>>>> says "offering" with an ingratiating smile for maximum effect) to
>>>>>>>> write some Verilog or VHDL. Given a reasonably competent and
>>>>>>>> territorial FPGA guy, this usually prompts a response of "here,
>>>>>>>> Tim,
>>>>>>>> let me take that off your hands".
>>>>>>>
>>>>>>> I think it's more like the FPGA guy feels you are offensive to the
>>>>>>> art of FPGAs. Maybe not truly dangerous, but not the sort of
>>>>>>> thing an FPGA guy wants to think about. I haven't worked with you
>>>>>>> obviously, I'm just going from your description. :)
>>>>>>
>>>>>> You're probably right. I believe that I have a pretty good grasp
>>>>>> of what's possible with FPGAs, but I'm not an experienced or even a
>>>>>> hugely interested practitioner.
>>>>>
>>>>> I was a bit confused by your description of using HDL. You do use
>>>>> HDL now, right?
>>>>
>>>> Yes, although my favorite HDL is a block diagram and a bunch of math,
>>>> handed to someone like you. It works ever so much better for
>>>> everyone on the project than me banging out Verilog or VHDL.
>>>
>>> Yeah, see, that is the part where it gets dangerous. Not trying to be
>>> rude, but when you "sort of" know how to do something, that is when
>>> mistakes get made. HDL isn't so horribly hard, but there are
>>> subtleties that can cause hard to debug problems. When you only do
>>> something once in a while and nothing very big, you never really learn
>>> all the details.
>>
>> <snip>
>>
>> Well, that's why I prefer to hand my system designs to an FPGA expert
>> instead of trying to implement them myself. In general, if a customer
>> calls and wants FPGA work done I say "no" and explain why. If money
>> got tight and there was no other work available, and someone just HAD
>> to have ME do the FPGA work, then I'd (A) warn them one last time that
>> I'm just a hacker, and (B) deeply discount my time.
>
> You could refer the work to someone you know. If the work is bigger
> than just the FPGA work, you can sub it out to someone else. I did that
> on a project that was just too large for me and it worked pretty well. I
> did have one part I had to take over. I had worked with the guy one
> time and had not gained a full appreciation of the flake factor. In the
> end it was just moonlighting work for him and he gave it last priority
> over even his personal life. It worked out in the end.
>
>
>> I think I've done FPGA work for money twice: once was for a friend who
>> understood, and the work was deeply discounted; the other was for a
>> customer who had FPGA people on staff, but those guys didn't have time
>> to do the work when I did it. In that case the first communication I
>> got from the FPGA guy was "you're a software guy, aren't you?"
>
> Lol. It often shows, but being a software person doesn't automatically
> make someone a poor candidate for FPGA work. They just have to be a bit
> flexible and forget a *lot* of what they know about software. I guess
> it's hard to know what to forget and what to retain. It helps if they
> have someone more experienced to oversee the work and to review the
> results.
>
> In the other direction, I helped a friend who is a great hardware
> designer spin up on FPGA work. I did one module and turned it over to
> him with some one-on-one time to get him familiar with what I did and he
> was off and running.
>
>
>>> My main gripe with non-FPGA people is the frequent biases they seem to
>>> develop that FPGAs have to be power hungry, large and complex to work
>>> with. I mostly work with small devices that use little power from a
>>> single power supply where the only complexity is in the design itself.
>>> Not too many people appreciate these types of devices.
>>>
>>> As a demonstration I have wanted to design a battery powered WWVB
>>> receiver in an FPGA. Will do it some day.
>>
>> I want to see it! Most of the work that I've done when there are FPGAs
>> in the mix have been with processors doing the complicated slow stuff,
>> and FPGAs doing the (relatively) simple fast stuff -- things like video
>> processing, where the FPGA is fondling every pixel but the processor is
>> managing managing the transfer of lines over a digital data link (and
>> with a different digital link the processor would be further away than
>> that).
>
> Depending on how fast you need, there are some low power iCE40 devices
> from Lattice, since they bought Silicon Blue. Of course the power goes
> up with clock speed, but they start at nearly zero (100 uA) and go up
> linearly. They aren't real big and don't have multipliers, so likely
> not for the above design. The XP2 line has DSP blocks plus multipliers
> and would be lower power than many product lines, but not as low as the
> iCE40.
>
>
>> For me, at least, I find that to do designs in an HDL I essentially
>> have to think at the same level of detail that I do when writing code
>> in assembly -- trying to get more abstract, at least for me, leads to
>> lots of wasted gates and unexpectedly long propagation times.
>
> It helps to think in terms of the functional blocks that are optimal for
> FPGAs. Adders are good, but you can often avoid an extra adder by
> making sure the carry out can be used for a compare operation. Any time
> you do an operation on a bus, consider how it would be implemented.
> Muxes eat up LUTs and can often be combined with an adder by zeroing an
> input. It all depends on the design. Sometimes the design just eats
> LUTs and there's nothing to be done other than minor optimizations.
>
> The problems with HDL don't come from these sorts of issues though. They
> come from misusing the language. Which do you work in, VHDL or Verilog?
I am equally inept in either one. Really, I think that at my level it
has less to do with the language and more to do with not having an
intuitive grasp of what's going to fit well with a given FPGA structure
vs. what's not, and if I'm not careful I start to think sequentially,
which translates to long if-then-else chains in either language, which
get synthesized as these really wide-to-one MUX's with high delays in the
chip.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I'm looking for work -- see my website!