Choice of Language for FPGA programming
in [FPGA]
|
Prev: OpenSPARC T1 or T2 on Altera EP2S60 or EP2S90
Next: Where to find source code for Xilinx ML507 board demos?
From: Nico Coesel on 4 Sep 2009 13:35 Andy <jonesandy(a)comcast.net> wrote: >FPGA's are not processors, so FPGA's are not "programmed" by a >language per se. They are designed, and the design is specified using >a schematic or a language, usually verilog or vhdl. "Programming" an >fpga usually refers to downloading the design configuration data into >the FPGA (i.e. via the JTAG port you mentioned. The FPGA and/or board >vendor will provide utilities to "program" the FPGA with your design >configuration data. I still see no difference between the development flow for a cpu and an FPGA. Its all about idea -> specification -> implementation -> verification / testing. The only real difference is that a CPU executes a program sequentially and an FPGA executes its program in parallel. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" --------------------------------------------------------------
From: Jonathan Bromley on 4 Sep 2009 18:31 On Fri, 4 Sep 2009 07:45:31 -0700 (PDT), johnp wrote: > The real problem I see is that no matter what the > language, at some point you have to deal with > clock domain crossing, meta-stability, setup/hold >issues, logic depth, etc. Indeed so. But none of those things is in any significant way affected by your choice of design entry language. However, I agree that... > Neither language can eliminate these traps. A > newbie who comes into h/w design from a > s/w background probably doesn't appreciate > how tricky these problems can be. That, too, is unquestionably true. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ My advocacy of VHDL over Verilog for RTL design, which is of course quixotic, has much more to do with coding style and re-use concerns. Although SystemVerilog has added some nice features for re-use (packages, typedefs, array query functions) it still has nothing that even comes close to the power and elegance of VHDL's unconstrained array types and dynamic elaboration of subprograms, and the consequent ability to write highly generic subprograms that can be used in a huge variety of designs. If the comparison is with vanilla Verilog, VHDL simply leaves it lying in the dirt. Verilog advocates just don't go there; they get their re-use in other ways that don't depend on Verilog's weaknesses, but instead make use of scripting languages and other non-Verilog tools. I can't see why that is a good idea when VHDL gets it right anyway. Other things that VHDL gets right: the distinction between variables and signals, which sweeps away the need for all that "blocking vs. nonblocking" style-guidance BS in Verilog; the ability to execute arbitrary procedural code at elaboration time, allowing you to use the full power of the language to parameterize your designs; absence of arbitrary limitations on the data type of a port; elaboration-time assertions to check that a parameterizable module has been deployed correctly. And ALL of that has been usable since the very start of VHDL, unlike Verilog which grafted on some of the better design features in its 2001 language revision. Elaboration-time assertions have only this year been added to SystemVerilog, and aren't yet available for use. On the other side of the debate, SystemVerilog adds a raft of interesting new RTL-friendly features: "unique" and "priority" qualifiers on conditionals (although the 2005 definition was somewhat flawed, prompting some significant fixes in the upcoming SV-2009 standard); specialized process templates (always_comb, etc) for modeling RTL designs; shorthand port connection using .*; packed structs and unions; type parameterization. Every one of those things *could* be added to VHDL, but most VHDL folk don't really see the point because VHDL already allows you to do the same things in other ways. Finally, there's the one feature in SystemVerilog that really promises to revolutionize the way we think about RTL design: the interface construct. VHDL has nothing to match it. Interfaces should allow us to write designs that are generic in ways that have never before been accessible. But, as I've argued in public on a number of occasions, interfaces in SV are broken and simply don't do what's needed for truly powerful re-use. (There are non-RTL uses of interfaces that work just fine; it's the design applications that bother me.) ~~~~~~~~~~~~~~~~~~~~~~~~~~ OK, I've said it. Probably more than I should have said. All the above is strictly my personal musings, to be greeted with the usual ridicule. Of course I'm fully aware that the overwhelming majority of ASIC designs, and a good proportion of FPGA designs, are done in Verilog; that situation is unlikely ever to shift in favour of VHDL. And it's worth emphasising once again that my rant is entirely related to RTL design; I find SystemVerilog much more flexible for testbenches than VHDL. But I hope that what I've said might help to lift the discussion one level above the schoolyard arguments we hear so often: "Verilog is like C", or "Verilog lets you write designs with fewer lines of code, so there will be fewer bugs", or whatever. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley(a)MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
From: Andy on 5 Sep 2009 09:28 On Sep 4, 5:31 pm, Jonathan Bromley <jonathan.brom...(a)MYCOMPANY.com> wrote: > Finally, there's the one feature in SystemVerilog > that really promises to revolutionize the way we > think about RTL design: the interface construct. > VHDL has nothing to match it. Interfaces should > allow us to write designs that are generic in ways > that have never before been accessible. But, as > I've argued in public on a number of occasions, > interfaces in SV are broken and simply don't do > what's needed for truly powerful re-use. (There > are non-RTL uses of interfaces that work just fine; > it's the design applications that bother me.) I've been pining for what seems like forever to bring to VHDL a primitive yet powerful sort of interface that would be completely at home in RTL: user definable, custom port modes for record data types. Defining a record for an interface is so easy and intuitive, but the fact that, currently, the entire record (and every element in it) must be of one mode IN, OUT, INOUT, etc., means the only effective way to use them is to make the entire record port inout. This restricts the leaf-level types within the record to being resolved types, and requires a lot of fiddling around with default assignments to 'Z', (std_logic), etc. If we had a way to define custom modes for record types, on an element by element basis, this perverse use of resolved types and default driven values would not be necessary. Of course, a way to define more than one custom mode for most types will be necessary (e.g. master vs slave endpoints on a bus). But once the modes were defined, you could implement records with any data types you wanted (integer, enum, boolean, etc.), even other record types (with their own defined custom modes). The task of "hooking up" large structures with complex interfaces would be simplified tremendously, as would the ability to plumb these complex interfaces through multiple levels of hierarchy via "conduits" through which we can virtually pull any kind of cable or fiber we might want, and even change our mind without massive rework. I've used this record technique to plumb generics throughout a design with great success (largely because generics are always inputs). I'm not a language expert, and I'm not sure what the syntax would need to look like for defining these custom modes, but it sure seems like a simple addition to the language that would reap huge dividends. Andy
From: Jonathan Bromley on 5 Sep 2009 10:15 On Sat, 5 Sep 2009 06:28:28 -0700 (PDT), Andy wrote: >I've been pining for what seems like forever to bring to VHDL a >primitive yet powerful sort of interface that would be completely at >home in RTL: user definable, custom port modes for record data >types. Didn't they put something a bit like that into VHDL-2008? Shame on me, I've not yet got fully up-to-speed with that. >If we had a way to define custom modes for record types, on an element >by element basis, this perverse use of resolved types and default >driven values would not be necessary. Of course, a way to define more >than one custom mode for most types will be necessary (e.g. master vs >slave endpoints on a bus). But once the modes were defined, you could >implement records with any data types you wanted (integer, enum, >boolean, etc.), even other record types (with their own defined custom >modes). All this is true, and it's one of the things that SV interfaces and modports do reasonably well. However, the real power of interfaces comes from their ability to import and export functionality (subprograms) to/from their connected modules. I'm not aware of any move towards that sort of thing in VHDL. It doesn't really work quite right in SV either, but at least they had a shot at it. >The task of "hooking up" large structures with complex interfaces >would be simplified tremendously, as would the ability to plumb these >complex interfaces through multiple levels of hierarchy via "conduits" >through which we can virtually pull any kind of cable or fiber we >might want, and even change our mind without massive rework. Absolutely. One of my ultimate goals is the creation of bus-agnostic peripherals: here's my DMA device; if I connect it to a Wishbone interface, it automatically inherits a Wishbone bus control state machine from that interface; connect it to AHB and it likewise inherits AHB control machinery... There was a nifty paper on that idea in the early days of SV: Jensen, Kruse and Ecker. SystemVerilog in Use: First RTL Synthesis Experiences with Focus on Interfaces. SNUG Europe 2004. But it never really got off the ground - too many language-inadequacy hurdles to overcome. I guess there's no point in sighing for what might have been.... -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley(a)MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
From: Jon on 5 Sep 2009 10:40
Sure, VHDL is better for a new user. Writing the same thing again and again and again and again helps you remember it. Jon |