Personal computing discussed
Moderators: renee, SecretSquirrel, just brew it!
just brew it! wrote:It appears that I'll soon be getting another hat at work, to add to add to the half-dozen or so (firmware developer, IT support, sysadmin, circuit-level hardware troubleshooting, marketing support, etc.) I already need to wear on a regular basis. This one is going to require me to do some FPGA design work!
bdwilcox wrote:I can see why you're "Somewhere, having a beer."
Madman wrote:Xlinx ISE and the related documentation should help, but "verilog tutorial" also comes up with some good picks. It all depends on how you like to study.
In general, VHDL and FPGA designing and debugging is pretty unpleasant if you have used to C++ and MSVS IDEs and development practices. Coding seems to be quite similar to C++/C except all that concurrency, cycles and register stuff, that is really hard to grasp.
just brew it! wrote:bdwilcox wrote:I can see why you're "Somewhere, having a beer."
Hey, versatility is one of the best defenses in a crappy job market. While it does sometimes make for days which consist of nothing but interruptions, I welcome the experience. It makes me more valuable to my employer (so less likely to be one of the first to be let go if there's a layoff), and opens up additional possibilities should I need to find another job.
Richie_G wrote:Surely it should be 'Somewhere else, having another beer' by now?
DancinJack wrote:I learned some VHDL in college and it was all done by reading a book and trying stuff out. I dunno, i think it just takes time to get used to. Here are some online things that might help.
http://equipe.nce.ufrj.br/gabriel/vhdlfpga.html
Wajo wrote:Personally, I've had more success trying to avoid seeing VHDL as I would a programming language and think in terms of hardware (register transfers, timers and such), particularly because of the nature of the execution (everything happening at once, etc.). Some people simplify things by implementing hardware in the form of state machines, however I'm not sure if there would be a performance trade-off by doing this.
balzi wrote:what is truly awesome about this - is that they've gone in house to develop something when their resource (JBI) obviously couldn't do it, but they knew he eventually could do it. that's a great employer.
just brew it! wrote:Heh... if you'd witnessed first-hand the series of events which led to the creation of this project (and me being asked to do some of the FPGA work) you probably wouldn't think so!
But, at the end of the day I still get to learn something new and interesting so overall I'd say it is a net positive.
balzi wrote:did you get yourself a USB digital analyser? There's better ones out I expect, but I'm happy with the sucker I got here http://www.pctestinstruments.com/.
My favourite part is the incredibly flexible triggering to capture.. oscilliscopes are great, but this lets you do so much more when messing with digital signals only.
just brew it! wrote:Wajo wrote:Personally, I've had more success trying to avoid seeing VHDL as I would a programming language and think in terms of hardware (register transfers, timers and such), particularly because of the nature of the execution (everything happening at once, etc.). Some people simplify things by implementing hardware in the form of state machines, however I'm not sure if there would be a performance trade-off by doing this.
The application at hand is (primarily) concerned with video processing. Sort of like a custom GPU, with multiple pipelines processing groups of pixels. So I imagine state machines will likely be the way to go...
liquidsquid wrote:All I know is switching from VHDL coding to C# to assembly and back really makes my head hurt.
liquidsquid wrote:All I know is switching from VHDL coding to C# to assembly and back really makes my head hurt. Something about the different mentalities makes throwing VHDL into the mix an almost impossible task for me. One or the other at a time, not both. Oh, lets try to toss a little board layout in there too. Oil and water...
Working with FPGAs is simply far too much fun, as those things can scream out some impressive number-crunches. Humongous FFTs far faster than a PC could ever hope, video processing, encrypting, software defined radios... However, I have found that because of that mix of different sides of the brain mentioned above needed to write excellent VHDLwhile performing other tasks, I had to divorce myself from VHDL and let the guys who specialize in that stay with it. Much more efficient in the end.
The book mentioned above is an excellent one, I use it as a reference a lot, but hopefully not for a while again.
-Mark
just brew it! wrote:you actually need to visualize it moving along wires between different logic blocks... bare metal indeed!
SecretSquirrel wrote:Are you using a 3rd party IP block for the memory controller, or are you jumping in the deep end and rolling your own?
SecretSquirrel wrote:There is a huge difference in simulation and the physical world. On the face of it, it would appear that there is much more to VHDL that will not synthesize that in Verilog, but that may just be my familiarity with Verilog. I've been through VHDL classes and wasn't really impressed.
SecretSquirrel wrote:Congrats on making progress though. FPGA stuff is something I have tinkered with as a hobby/play thing until just recently. Now I support an FPGA based hybrid co-processor architecture and system. Major change in jobs and focus, but I'm looking forward to the challenge.
SecretSquirrel wrote:As someone mentioned earlier in the thread, you have to think of things in terms of wires, gates, and flip-flops. Programming constructs that don't line up don't synthesize well. Of course I still get told be EE friends that I write Verilog like a software guy.
Flying Fox wrote:just brew it! wrote:you actually need to visualize it moving along wires between different logic blocks... bare metal indeed!
Sometimes you do have to do that with a scope and look at signal waveform, literally.
just brew it! wrote:SecretSquirrel wrote:Are you using a 3rd party IP block for the memory controller, or are you jumping in the deep end and rolling your own?
We're currently using Altera's DDR3 controller IP. It's a PITA. We may eventually end up keeping just their PHY and re-rolling the rest of it ourselves, but we've got bigger fish to fry right now.SecretSquirrel wrote:There is a huge difference in simulation and the physical world. On the face of it, it would appear that there is much more to VHDL that will not synthesize that in Verilog, but that may just be my familiarity with Verilog. I've been through VHDL classes and wasn't really impressed.
Most of my newbie type mistakes were more along the lines of stuff that would still synthesize, but made the design difficult to debug once it was on the real hardware. Well, and then there was the hand-coded dual-port RAM block which didn't map cleanly to the FPGA's canned RAM arrays, causing the synthesis tool to build the entire memory array out of logic gates; this caused compile times to increase exponentially (18 hours)!
just brew it! wrote:Edit: I also didn't realize until a month or so ago (when I started trying to test on "real" hardware) that creating tri-state busses internal to your design (as opposed to tri-state external interfaces) is frowned upon. I ended up ripping all of the tri-state signals out of my design and replacing them with muxes.
just brew it! wrote:SecretSquirrel wrote:Congrats on making progress though. FPGA stuff is something I have tinkered with as a hobby/play thing until just recently. Now I support an FPGA based hybrid co-processor architecture and system. Major change in jobs and focus, but I'm looking forward to the challenge.
Thanks. There's a soft MIPS core processor in this design too (compiled into the FPGA). Someone else has been working on that piece, but once my block is fully debugged I will need to interface it to the processor.SecretSquirrel wrote:As someone mentioned earlier in the thread, you have to think of things in terms of wires, gates, and flip-flops. Programming constructs that don't line up don't synthesize well. Of course I still get told be EE friends that I write Verilog like a software guy.
Oh, I'm sure I write VHDL like a software guy too! It looks just enough like C code to get you in trouble...
Edit: The whole parallel vs. sequential thing is a major brain-bender. And then there's the whole business of making sure you don't create logic blocks that force the synthesis tool to create transparent latches behind your back...Flying Fox wrote:just brew it! wrote:you actually need to visualize it moving along wires between different logic blocks... bare metal indeed!
Sometimes you do have to do that with a scope and look at signal waveform, literally.
During debugging you need to look at signals internal to the chip that don't make it out to the external pins. The tools allow you to compile a "soft" logic analyzer right into the FPGA, which then talks to your workstation to display the waveforms. The downside is adding or moving "probes" takes half an hour because you need to recompile the entire design!