You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!
Arturo's comments on the latest SV-CC OO proposal may be indicative of how unstable SystemVerilog really is.
Back at the start of the SV standardization process, I was hopeful that we were going to get some simple way of bridging between Verilog and C then C++/SystemC - I made some proposals myself since we had a Verilog & C++ verification environment at Nat Semi.
A decade or so on it doesn't seem like we're any closer, and given that most simulators just translate SV to C/C++ and compile it, it seems like this should be an easy problem to solve - makes you wonder what they're planning for the hard problems.
Perhaps it's equally that the changes didn't develop exactly in the way Arturo proposed?
"just translate SV to C/C++ and compile it, it seems like this should be an easy problem to solve"
Surely this is different from the problem they seem to be trying to address: how to translate between SV and C so that two pre-existing user communities can share and modify-or-extend definitions. This could be a very different task from translating into executable code.
Possibly a misunderstanding on my part - I'm both Europe based and specialis in analogue design
I'm European & analog guy too, I got involved in SV to make sure we didn't have a conflict combining Verilog-AMS. I was pushing for SV/C++ interoperability back at the start of SV, and gave up - the SV-CC committee was probably the worst of the SV committees I participated in (from a technical standpoint), you can check the reflector history. Most of the guys on the committee know very little about the workings of C++ at the linker level - try polling for who knows what a "thunk" is.
By using classes and parsing Verilog code to personalize the objects, a C++ model of the HW function is possible. Then both HW and SW are in the same language so there is no need for a bridge between 2 different languages and no need to translate and compile. Posted by Karl
By using classes and parsing Verilog code to personalize the objects, a C++ model of the HW function is possible. Then both HW and SW are in the same language so there is no need for a bridge between 2 different languages and no need to translate and compile. Posted by Karl
I am focused on the simple case of getting a single piece of HW and the associated SW to run in a functional mode rather than RTL and signal waveforms. I see no need for multithreading when making HW/SW tradeoffs. All the concern over HW parallelism is simply that registers and arrays can change at the same time(clock). Verilog has blocking/non-blocking assignments. Verilog has ports, objects have properties. Edge triggered regs hold din then change q. Objects can have a din property that can be set and a method to assign q = din; HW is simply regs and arrays that can be assigned and hold values, and logic circuits that can resolve Boolean logic.
During verification, not synthesis is "multithreading" useful. Then use HW or HW model. Posted by Karl
Hardware is intrinsically a parallel/multi-threaded implementation of an algorithm. Verilog & VHDL are essentially parallel processing languages, they are just poor general purpose languages. Software is moving to being parallel/multi-threaded in general, and for high thread counts the software methodology is going to look a lot like hardware design. IMO the best way to write code for a parallel world is to write it with as many threads as possible and let the compilers serialize it if necessary.
Yep, and you could use C++ object pointers as PLI "handles" which would have be a simple backward compatible way to make it more efficient. Unfortunately they reinvented it badly as DPI for SV. I'll say nothing about VPI.
A major problem with Verilog is that it was invented a long time ago, when folks didn't use power management, and wiring delays were not dominant. SV has not fixed those issues, and most of the functionality added in SV could be done in C++ such that it would also work for SystemC (and software test).
Every time an issue comes up, it is assumed that a new language is needed. There are very few computer science types actually designing chips so the designer usually responds "I don't want to learn a new language -- I want a tool that works!!!!!!!!" Without getting into whether FPGA or ASIC is the most important, The FPGA design task is to connect memory blocks with flip-flops to perform a logical function. The original synthesis tool converted if/else statements to logic gates, but since it was the only game in town, the input source for FPGAs also used if/else as the basic logic description even though there is not a single logic gate available on an FPGA. This goes back to the mid 80's.
In HW design "modules" are created and inter-connected physically and logically. In SW design, objects are created from classes and are connected logically. If given classes that represent arrays and integer variables for registers an analogous task is now in a SW environment.
Did I forget about CLOCKING? How about a setup method and a launch method in the register classes? Just call setup() for every register to set din. Then call launch() for each to set the new q.
But what about generating HDL? Don't do it, instead generate a netlist like the FPGA vendor does to support third party tools and whatever input P & R needs.. Posted by Karl
Every time an issue comes up, it is assumed that a new language is needed. There are very few computer science types actually designing chips so the designer usually responds "I don't want to learn a new language -- I want a tool that works!!!!!!!!" ... Posted by Karl
Unfortunately there are "computer science types" working in EDA that love to create new languages, but they don't overlap much with folks that actually understand electronics, so the results are variable. Regardless of the base language it's the semantics that are important - if you can't describe what you want the tools will not work for you, and if you can't model hardware properly you won't be able to verify it. None of SV, Verilog or VHDL can accurately describe modern ICs, which leaves you having to use Spice level descriptions.
Is there a link to any info about using Spice in place of Verilog? Seems to me the two have completely different applications.. As far as the dominance of wiring delays, my recollection is that Verilog came before the use of copper for on chip wiring and that was when wiring delays were really a big factor. Logic design and physical design have different tools and rightly so. Meanwhile I am entertaining myself defining the 4 or 5 classes necessary to represent the chip logic so that it can be used in the same SW environment as the application development. Posted by Karl
Basically the idea with Verilog-AMS is that it is a pure extension of Verilog that will (eventually) replace Spice netlists (which are non-standard), and it will allow you (the user) to pick the level of accuracy you need. Ideally you can dissociate the device models from the simulator and make them portable.
Unfortunately analog engineers seem to be the only users of Verilog-AMS, and they hate changing tools, so the pace of change is glacial. Digital simulator developers are generally computer-science/digital guys that don't understand analog, so they just ignore any problem that appears to be analog ;-)
NB: the original language design for Verilog-AMS was aimed at getting better verification with wiring dominated digital (SoC) designs.
I think one area where this technology can really take off is in software/hardware co-verification. Software formal verification tools lag badly behind EDA tools. I think the growing adoption of functional programming languages will help in this area.
What Mathworks has done with the Mathlab/Simulink environment the past couple of years is really impressive. If you need a certifiable, highly automated workflow for aviation, medical and general IEC 61508 functional safety, take a look.
Its also becoming an impressive FPGA development environment.
I think one area where this technology can really take off is in software/hardware co-verification. Software formal verification tools lag badly behind EDA tools. I think the growing adoption of functional programming languages will help in this area....
- from an EDA perspective it replaces SystemC/SystemVerilog with C++ so that programmers can use it. I.e. if you use the same language for software and hardware it's easier to do the trade-offs/co-verification, and formal tools can work for a broader audience (writing parallel code is pretty much like hardware design if you have a lot of threads).
my recollection is that Verilog came before the use of copper for on chip wiring and that was when wiring delays were really a big factor. Posted by Karl
The change from aluminium/standard_K to copper/low_K makes less than a factor of three difference to wiring delays; this essentially held wiring delays down to the same proportionate level for about 1.5 generations of silicon.
So wiring delays are an increasingly a crucial factor for high-speed logic - especially when the traces cover more than a few logic cells. This is still a major reason that number of layers need to increase as geometries shrink
The change from aluminium/standard_K to copper/low_K makes less than a factor of three difference to wiring delays; this essentially held wiring delays down to the same proportionate level for about 1.5 generations of silicon.
So wiring delays are an increasingly a crucial factor for high-speed logic - especially when the traces cover more than a few logic cells...
The fact that wiring delays were going to be a major problem was obvious back when I started on Verilog-AMS - wiring resistance is the one thing that doesn't scale advantageously. Verilog-AMS was designed to handle switching between digital (discrete logic - 01XZ) and Spice-like analog simulations of interconnect (mostly Rs & Cs).
Unfortunately the EDA companies like to charge incrementally for licenses so they are not motivated to give you a working Verilog-AMS that does everything when they can sell you a Verilog and a Spice separately for more money - the fact that the later approach is pretty dysfunctional only hits them in the bottom line years later when their customers go out of business because their chips don't work or cost to much to design.
PS: I have built a "poor man's" Verilog-AMS with Icarus Verilog and Spice3/Gnucap, the code is online if anyone wants it.
