Verilog or VHDL? - Page 1
Forum section: electronics / general

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 12, 2016, 02:15:17 am
content: I'm curious how many people on this forum use Verilog and/or VHDL...

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2016, 02:56:50 am
content: Verilog, and even that is too verbose for my taste. I can't deal with the amount of typing required for VHDL.

author: exmadscientist
author_rank: Frequent Contributor
timestamp: August 12, 2016, 05:06:04 am
content: There are entire classes of stupid Verilog mistakes that are simply not possible in VHDL. Given that hardware design is challenging enough, I'm happy to trade a bit of verbosity for a lot of type-safety.(And it's not like VHDL is that verbose, anyway, given its domain. It's certainly a lot more pleasant to write than yet anotherAbstractFactoryConstructorDelegationVisitorSingletonFactory!)

author: scatha
author_rank: Regular Contributor
timestamp: August 12, 2016, 06:02:27 am
content: It depends on the existing project codebase - if it's Verilog I use Verilog, VHDL then I use VHDL. Mixed-source projects can be a pain because invariably someone's chosen port names which are reserved keywords in the alternate language.I've been too mentally scarred by other people's horrible, horrible Verilog to use it in my personal projects - I tend to use VHDL for synthesis and SystemVerilog for verification which gives me the best of both worlds.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: August 12, 2016, 07:26:36 am
content: I am a hobbiest and invested in learning a bit of VHDL. Being a C/C++/C# developer I am amazed at the verbosity of the syntax and cannot yet type a simple 'program' without looking stuff up - probably because I do not use it very often.As I learned PSoC5 and their(Cypress) Creator software I have looked into Verilog and it looks a lot simpler, but have not invested in learning that. But I probably will when I need to do some advanced custom components...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 12, 2016, 07:45:46 am
content: Quote from: exmadscientist on August 12, 2016, 05:06:04 amThat's the reason I chose VHDL - I'm sure if I used it a lot I'd prefer Verilog, and find some aspects of VHDL just plain stupid (e.g. no block comments or #define/#ifdef), but as I only do maybe one FPGA project a year, I'm never going to get really familiar with it, so any help the language can give to avoid mistakes is welcome.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 12, 2016, 08:15:42 am
content: I use VHDL as that was the language used in an old University Text book I got for $5 at a bookshop sale before I purchased my first FPGA board.

author: nctnico
author_rank: Super Contributor
timestamp: August 12, 2016, 08:15:52 am
content: Quote from: mikeselectricstuff on August 12, 2016, 07:45:46 am#define #ifdef is certainly there. Create a package with some constants (number of channels, options, etc), include that package in your VHDL sources and use 'if ... generate' to include or exclude certain parts.In general: the trick to use VHDL efficiently is to treat it as a programming language. Too many people are still describing logic instead of a solution for the problem they are solving. It is like programming C using lots of inline assembly and that leads to a lot of typing.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 12, 2016, 08:41:20 am
content: Quote from: nctnico on August 12, 2016, 08:15:52 amIsn't the stuff within generate blocks still parsed, so it has to be 'correct' code? (e.g. signals need to be defined, no hanging nested 'if's... )

author: Cerebus
author_rank: Super Contributor
timestamp: August 12, 2016, 09:23:31 am
content: VHDL was designed by a committee, a military committee. That single sentence ought to be enough to steer any sane person away from it.I can pretty much guarantee that almost every bit of VHDL that anyone here has ever seen or written begins (excluding possible comments) with the lines:Code:library IEEE;use IEEE.std_logic_1164.all;A hint that there's something fundamentally flawed is when what are essentially the fundamental types most commonly used in a programming language require definition for each and every program, and require you to type something to invoke that definition.When defending VHDL people always say "type safety" as if it's some magic mantra. Type safety is a wonderful thing, and I heartily encourage anybody designing a programming language to adopt it. The thing is type safety doesn't require an abstruse syntax that requires repeated, pointless verbiage1. A hint, if you claim type safety is important to you and also choose to program in C you don't really care about type safety and you're using "type safety" as a mantra to defend your choice of VHDL. It's like buyer regret when a car buyer defends their car on its great fuel mileage and you can see their disappointment that they didn't get the little red sports car2.Another hint is in that second line of code. It's the ".all". If you're aiming for as much compile time checking as possible it's a bad idea to design a language in a way that encourages users to include every type in a type library including all the types they don't intend to use. You can't check for unintended type usage if you've set yourself up to encourage unintended type definition.If you're determined to use VHDL my primary recommendation is a touch typing course, you'll need it.1 The syntax of VHDL is modelled on ADA. As well as being user hostile, the ADA syntax is compiler hostile too. It's one excuse to mangle the formal syntax of a programming language to make it easier for the users, it's another excuse to make it easier for the compiler writer, but mangling it for both is close to a useful working definition of insanity. As they say in the British Army: "There are three ways to do a job. There's the right way, the wrong way and there's the Army way.".2 The authordoeshave a little red sports car, and has few if any regrets.

author: Kilrah
author_rank: Unknown
timestamp: August 12, 2016, 09:39:12 am
content: Quote from: Cerebus on August 12, 2016, 09:23:31 amIt's different, you usually don't program in C because youchoseto, it's just that it's where everything is. If you later get to choose your HDL you might want to precisely try something else that hypotherically could help you avoid the mistakes you know all too well about.I find VHDL verbosity to be a pain mostly for instatiation/port mapping. There should be implicit maps that can be overridden if needed (e.g. using external components), but when you design your own components and system you shouldn't need to type each signal name umpteen times.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 12, 2016, 09:53:04 am
content: Quote from: Kilrah on August 12, 2016, 09:39:12 amThis works just fine:Code:architecture Behavioral of tb_debug_test iscomponent debug_test isPort ( clk : in STD_LOGIC;serial_out : out STD_LOGIC;probes : in STD_LOGIC_VECTOR (8 downto 0));end component;...begin...i_debug_test : debug_test port map (clk, serial_out, counter);...Let us know how well it works out for you...

author: nctnico
author_rank: Super Contributor
timestamp: August 12, 2016, 09:58:03 am
content: Quote from: Kilrah on August 12, 2016, 09:39:12 amBTW Nowadays a good C/C++ compiler throws an error if you use the wrong type and don't explicitly cast it.QuoteYou can use packages (only one component instantiation) and records to reduce the amount of text significantly. If you have a bunch of related variables in C you typically put them in a struct and pass the struct to a function instead of each variable seperately.

author: Kilrah
author_rank: Unknown
timestamp: August 12, 2016, 10:24:31 am
content: Quote from: hamster_nz on August 12, 2016, 09:53:04 amWell you still need internal signals, don't you?What I mean is that the following:Code:entity design_1 isport (btn : in STD_LOGIC;clk : in STD_LOGIC;led : out STD_LOGIC;sw : in STD_LOGIC_VECTOR ( 3 downto 0 ));end design_1;architecture STRUCTURE of design_1 iscomponent design_1_clk_wiz_0_0 isport (clk_in1 : in STD_LOGIC;clk_out1 : out STD_LOGIC);end component design_1_clk_wiz_0_0;component design_1_pwm_0_0 isport (clk_i : in STD_LOGIC;reset_i : in STD_LOGIC;led_o : out STD_LOGIC;val_i : in STD_LOGIC_VECTOR ( 3 downto 0 ));end component design_1_pwm_0_0;signal btn_1 : STD_LOGIC;signal clk_1 : STD_LOGIC;signal clk_wiz_0_clk_out1 : STD_LOGIC;signal pwm_0_led_o : STD_LOGIC;signal sw_1 : STD_LOGIC_VECTOR ( 3 downto 0 );beginbtn_1 <= btn;clk_1 <= clk;led <= pwm_0_led_o;sw_1(3 downto 0) <= sw(3 downto 0);clk_wiz_0: component design_1_clk_wiz_0_0port map (clk_in1 => clk_1,clk_out1 => clk_wiz_0_clk_out1);pwm_0: component design_1_pwm_0_0port map (clk_i => clk_wiz_0_clk_out1,led_o => pwm_0_led_o,reset_i => btn_1,val_i(3 downto 0) => sw_1(3 downto 0));end STRUCTURE;Should be possible to express with:Code:entity design_1 isport (btn : in STD_LOGIC;clk : in STD_LOGIC;led : out STD_LOGIC;sw : in STD_LOGIC_VECTOR ( 3 downto 0 ));end design_1;architecture STRUCTURE of design_1 issignal clk_wiz_0_clk_out1 : STD_LOGIC;beginclk_wiz_0: component design_1_clk_wiz_0_0port map (clk_in1 => clk,clk_out1 => clk_wiz_0_clk_out1);pwm_0: component design_1_pwm_0_0port map (clk_i => clk_wiz_0_clk_out1,led_o => led,reset_i => btn,val_i(3 downto 0) => sw(3 downto 0));end STRUCTURE;I.e.- Skip the component port declaration, that should be inferred straight from the component's source. Copypasta between the component and the entity that instantiates it is ridiculous...- Skip the local signals that have no other purpose than connecting a port of the entity straight to a port of a component, connect those directly- Local signals that are used to connect ports between components are fine, they're required due the possibility of having multiple instances of the same component, no issue there.You already save half the code lines, and it seems you don't lose anything. You need a little more back and forth between files to check component declarations when doing the mapping, but I'd take that any day over having to copy them across and maintain that copy, every language requires that kind of thing anyway.Disclaimer: I'm pretty much a beginner in VHDL and I'm probably missing something including the possibility that my proposed version could be OK, and I've never tried verilog so maybe that does just this - if so I'd happily have a look at it, I'm here to learn!Note: obviously modern tools e.g. Vivado are able to hide that away from you by autogenerating the top module from the much easier to specify graphical block diagram, but still.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 12, 2016, 10:52:40 am
content: Quote from: nctnico on August 12, 2016, 08:15:52 amYou can do some things using constants but it's often more fiddly and there are some things you just can't easily do. I'm specifically thinking build variants where you may want to selectively include/exclude whole blocks, or have completely different functionality, which #ifdef could do much more easily.#ifdef would also be an easy way to work round the lack of block comments for temporarily disabling sections for debugging.

author: Kilrah
author_rank: Unknown
timestamp: August 12, 2016, 11:01:19 am
content: OK, just ran a quick test, and interestinglyQuote from: Kilrah on August 12, 2016, 10:24:31 amThis seems perfectly fineQuote from: Kilrah on August 12, 2016, 10:24:31 amBig nope for that one thoughThat's already something though! I'm all for fewer indirections, having to create and assign useless signals was nothing other than an opportunity for mistakes IMO.And that was another learning opportunity to port a design from a board to another , and integrate some autogenerated code from a Vivado block design into a pure code project. I'm starting to get a hang of the tools and their "behind the scenes" workings if anything

author: asgard20032
author_rank: Regular Contributor
timestamp: August 12, 2016, 11:35:13 am
content: I tried both, and there is mostly one thing I would like to be ported to Verilog : type. Being able to create a type, like an enum, for state machine, is a clean approach. Just implement something like enum/type for Verilog just for the sake of state machine.

author: parasole
author_rank: Contributor
timestamp: August 12, 2016, 12:48:07 pm
content: I learned FPGA programming myself as hobbyist, initially started with Verilog, however it turn out VHDL to be much easier to learn and understand... By now I am doing every thing in VHDL and use Verilog only as readily available functions, although may adjust them to my need if required...

author: Someone
author_rank: Super Contributor
timestamp: August 12, 2016, 01:16:14 pm
content: Quote from: Kilrah on August 12, 2016, 11:01:19 amTime to learn the entity declaration:http://insights.sigasi.com/tech/four-and-half-ways-write-vhdl-instantiations.html

author: dmills
author_rank: Super Contributor
timestamp: August 12, 2016, 01:25:33 pm
content: I come from the background of having an expert knowledge of C, so I quite deliberately set out to learn VHDL, Verilog is just sufficiently C like that I find myself in a 'software' mindset and HDL written as if it was sequentially executing software is horrible when it works at all.The verbosity is a price worth paying for making things explicit IMHO, and do NOT underestimate that type safety thing, annoying? Sure, but less so then trying to figure out why the thing has guessed wrong about a signed/unsigned math operation.Regards, Dan.

author: rstofer
author_rank: Super Contributor
timestamp: August 12, 2016, 02:16:04 pm
content: Quote from: Cerebus on August 12, 2016, 09:23:31 am#include <stdio.h>#include <stdint.h>

author: legacy
author_rank: Super Contributor
timestamp: August 12, 2016, 03:10:37 pm
content: vhdl under CoNix with ghdl + gtkwave (sometimes ModelSim) and ISE-v14.1edit:oh, I am also tempted by VHDL-AMS(1), it's a derivative of VHDL(IEEE standard 1076-1993), and it includes analog and mixed-signal extensionsbut ... it's not supported by ghdl(1) you can, in the theory, describe a PLL, or things that require pspiceso, it sounds interesting, in the theory, where in the practice it's uselessmainly because you can't find an useful tool

author: Kilrah
author_rank: Unknown
timestamp: August 12, 2016, 03:17:55 pm
content: Quote from: Someone on August 12, 2016, 01:16:14 pmInteresting, thanks for the link!Seems "Four-and-a-half" matches what I'd like, unfortunately it doesn't seem to work in Vivado (seems to be equal to "One", only works if the declaration is present)."Four" does the job, but a caveat is that it won't work if the component is written in Verilog, have to go back to "One" again for those.Haven't tried "Two" yet, "Three" just seems too messy to use.

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2016, 03:36:42 pm
content: Quote from: asgard20032 on August 12, 2016, 11:35:13 amThen you need to look at SystemVerilog. It implements many new features like this, while keeping syntax clean and simple.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 12, 2016, 03:42:31 pm
content: Interesting results so far. Most of the responders have been from Europe or Oceania, so the skew towards VHDL isn't surprising as those are two VHDL strongholds. It'll be interesting to see if the results change as North Americans wake up and cast their votes. Out where I am (Silicon Valley), HDL usage tends to heavily favor Verilog.I cast my vote for "both" because I just got started with FPGAs a few weeks ago and haven't decided whether I like Verilog or VHDL best. Each has its strong points and annoyances, so I'm alternating between them until I settle on one or the other.I find VHDL too verbose for my taste, and its extreme type safety just too much. I'm primarily an embedded C type, so perhaps if I worked in Ada I wouldn't be so turned off by this.Verilog is more like what I'm used to in a language, but it also has its issues. I'm constantly forgetting the differences between blocking and non-blocking assignments and constantly forgetting to use "assign" before a con-current statement. Since Verilog is so C-like already, I wish that they'd made it a little more succinct by using {}s rather than begin/end.

author: kfnight
author_rank: Regular Contributor
timestamp: August 12, 2016, 04:12:03 pm
content: For design I use a safe-subset or lowest-common-demoninator of Verilog/SystemVerilog that I know will work on most EDA tools. It sucks because if I could use some of the newer features of the language my productivity would increase and the code intent would be more readable, but it's always one damn tool that doesn't support that new feature, so I gotta wait like 5 years for everyone to catch up before I can use it.

author: mark03
author_rank: Frequent Contributor
timestamp: August 12, 2016, 04:37:37 pm
content: Just thought I should mention that there are other alternatives, e.g. the Python-based MyHDL:http://www.myhdl.org/start/why.htmlBefore anyone hears "Python" and gets their hackles up, this is *not* a high-level synthesis project, rather a mapping of HDL essentials into Python syntax. The principal author happens to be a European who prefers VHDL, and he considers MyHDL as inheriting many of VHDL's best features, only with less verbosity. The tools convert MyHDL into either language for importation into your vendor toolchain.From my naive perspective as a rank beginner in FPGA design, he makes some compelling arguments. The ability to write your testbenches in Python seems like a big win, particularly for DSP.Thoughts or opinions?

author: sporadic
author_rank: Regular Contributor
timestamp: August 12, 2016, 04:39:53 pm
content: NoMyHDLlove?EDIT: Looks like I was a little late on hitting submit

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2016, 04:40:05 pm
content: Quote from: mark03 on August 12, 2016, 04:37:37 pmMarginal thing that will never be useful. Plus adding Python syntax introduces a lot of inconveniences. Programming languages are for programming, HDL languages are for hardware design.

author: mark03
author_rank: Frequent Contributor
timestamp: August 12, 2016, 04:54:52 pm
content: Quote from: ataradov on August 12, 2016, 04:40:05 pmI'm not sure you understand what the project is about. That is why I took pains to point out that itisan HDL, not a higher-level abstraction. It just happens to be built using Python syntax. (Python can be stretched much further than most people realize. In the case of MyHDL it turns out that an obscure feature called "generators" is just the thing for expressing concurrency in an HDL.)

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2016, 04:56:58 pm
content: Quote from: mark03 on August 12, 2016, 04:54:52 pmYes, but why? I'd rather use a language with syntax specifically designed for target application.

author: Kilrah
author_rank: Unknown
timestamp: August 12, 2016, 05:18:43 pm
content: Quote from: Sal Ammoniac on August 12, 2016, 03:42:31 pmI forgot to mention in the poll context that while I consider myself a beginner I have "picked" VHDL because that's we used during my enginnering studies 12 years ago, so it made more sense to make use of the little remains there might be in my memory. So yes, region-biased

author: mark03
author_rank: Frequent Contributor
timestamp: August 12, 2016, 05:53:28 pm
content: Quote from: ataradov on August 12, 2016, 04:56:58 pmWell, the developer, an experienced ASIC designer, clearly feels that his syntax is superior to VHDL's. It wouldn't hurt to at least hear him out. I know I asked for "opinions" but it would be polite to read his arguments and respond on the merits (or demerits).

author: suicidaleggroll
author_rank: Super Contributor
timestamp: August 12, 2016, 05:54:36 pm
content: Quote from: Kilrah on August 12, 2016, 05:18:43 pmSame here, but the University I went to also used VHDL even though it's in the US.

author: lem_ix
author_rank: Regular Contributor
timestamp: August 12, 2016, 06:46:22 pm
content: I like that VHDL is very different from C. Easier for me to keep a different mindset while "coding"/describing.

author: asgard20032
author_rank: Regular Contributor
timestamp: August 12, 2016, 07:37:57 pm
content: Quote from: ataradov on August 12, 2016, 03:36:42 pmI like what I read so far about system verilog. The only problem is that not every tool support it. Does Quartus support it (what about the legacy Quartus version they use in most university because of cyclon II to cyclon IV... like DE2 board)? Does ISE support it? Does Vivado support it (yes for this one)

author: nctnico
author_rank: Super Contributor
timestamp: August 12, 2016, 07:42:23 pm
content: Systemverilog seems to me like it is similar to Borland Delphi with all the C/C++ stuff bolted onto Pascal. If you want the VHDL goodies then just use VHDL.

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2016, 07:42:38 pm
content: All reasonably recent versions of Quartus and Vivado (but not ISE) support it. I use iverilog for simulations, and it does not support it either, so I'm sticking with plain Verilog 2001.

author: photon
author_rank: Frequent Contributor
timestamp: August 12, 2016, 07:45:50 pm
content: Only a subset of SystemVerilog is synthesizable. The additions to Verilog mostly help verification.

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2016, 07:49:50 pm
content: Quote from: photon on August 12, 2016, 07:45:50 pmThat is true for every language.Quote from: photon on August 12, 2016, 07:45:50 pmWell, I particularly like structured data, for example. This helps to simplify module interfaces a lot.

author: Scrts
author_rank: Frequent Contributor
timestamp: August 12, 2016, 07:52:05 pm
content: I did a number of designs with VHDL and was happy with it. In general, I could have moved to Verilog at some points because of already written code that I had to learn and understand to re-use, but having records in VHDL still kept me the same way. I did not find verbosity to be a major problem for me.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 12, 2016, 08:09:55 pm
content: Quote from: photon on August 12, 2016, 07:45:50 pmTrue. Same goes for plain old Verilog and VHDL too.I like SystemVerilog's logic type (no more wire/reg nonsense) and always_ff/always_comb.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 12, 2016, 08:21:11 pm
content: Quote from: lem_ix on August 12, 2016, 06:46:22 pmI haven't noticed that. When I first started writing HDL, it didn't matter whether I was using Verilog or VHDL--I still tended to think in software terms. I have over 30 years experience as an embedded engineer, so those habits are deeply ingrained and were hard to break.I implemented almost everything at first as a state machine. This approach works, but can be unnecessarily complicated. It's familiar to embedded software types, which is why I suppose so many of us tend to use state machines for everything we do in an HDL. As an example, I recently implemented an SPI slave in SystemVerilog. I implemented it using a state machine that sequenced through eight states, and this took 289 lines of Verilog. After I got it working, I thought to myself, "hey, SPI is a very simple protocol and you're overthinking the problem." I started thinking about it at a purely hardware level and threw out the state machine approach and rewrote it in 36 lines. That's 253 lines shorter, and this version used 12 LUTs and 25 FFs versus 24 LUTs and 37 FFs in the state machine version.

author: legacy
author_rank: Super Contributor
timestamp: August 12, 2016, 09:17:02 pm
content: like this?it's written in vhdl, basically the psx_pad controller is an spi_masterwith a few customization by Sony, but my approach was ... too-fsm orientedresulting no less than 194 lines of code

author: rstofer
author_rank: Super Contributor
timestamp: August 13, 2016, 03:36:57 am
content: Quote from: mark03 on August 12, 2016, 05:53:28 pmI read the sales literature and have seen two other approaches to abstracting HDL into something else. Seriously, my indent level determines whether I am in a particular statement block? I have been messing around with Python and it has a lot of neat features for strings, lists, tuples and dictionaries. I got started because I saw an assembler in one page of code (something like that). Intriguing! But the syntax is abominable. I much prefer the rigid block structure of languages like Pascal, Modula 2 and Oberon. I think I'll like Ada if my fingers don't fall off typing...Were I to adopt MyHDL, I would need to learn two languages: MyHDL to write the stuff and VHDL to see if it compiled correctly. Do MyHDL and I agree on what I want to create?One of the sales points was that I didn't need to know whether my register represented an integer or a vector; the compiler would figure it out for me. I don't want the compiler to assume anything! If my code doesn't uniquely define some logical function, flag it and make me write it again! VHDL does just that: I either write it correctly or I write it again.On the separate issue of state machines, I don't see how you retain state without a state machine. Now, there are a number of ways to code state machines but you can't get sequential operation without maintaining state. In school we spent a lot of time minimizing state machines. Even in the days of the 2102 bit slices, minimizing states was important. Fortunately, there is only a minor penalty for having additional states (one more bit in the one-hot encoding) and the code becomes a lot more obvious. I don't see the point of obscuring the code in order to save a few flops when I have tens of thousands. I would rather the code tell a good story.But my code is going nowhere. It is strictly for a hobby, there is no pressure to use a smaller device and I don't want to clever myself into a hole.

author: asgard20032
author_rank: Regular Contributor
timestamp: August 13, 2016, 03:01:09 pm
content: Quote from: rstofer on August 13, 2016, 03:36:57 amQuote from: legacy on August 12, 2016, 09:17:02 pmQuote from: Sal Ammoniac on August 12, 2016, 08:21:11 pmI wonder if there are other methodology to develop than state machine, maybe some sort of variant of them. I doubt everyone do state machine, there are maybe other strategy. But fore sure, everything need a way to keep some sort of state. So those other strategy are maybe not a classic state machine like everyone else do, but are surely based on the same concept, but structured/implemented differently. Like in software programming, there are many design pattern, many different programming paradigm, even if some of those paradigm are similar...Maybe someone that did lot of study on FPGA or work in a big company using FPGA may know more about the different way to implement something.

author: ataradov
author_rank: Super Contributor
timestamp: August 13, 2016, 04:08:57 pm
content: Quote from: asgard20032 on August 13, 2016, 03:01:09 pmThere is a blend between CPUs and state machines - programmable state machines. Xilinx PicoBlaze is one, for example.Quote from: asgard20032 on August 13, 2016, 03:01:09 pmThere is nothing really wrong with state machines that needs changing.

author: rstofer
author_rank: Super Contributor
timestamp: August 13, 2016, 05:01:16 pm
content: There is no alternative to saving state. You can't build a sequential circuit without states. The question is: How do you code the FSM? I use the two-process approach, one clocked process that simply updates the current state and the other is just an unclocked process that does all the work.Another alternative that may result in lower resource usage involves writing logic combining the current state and various inputs to provide a specific output. Dozens and dozens of logic blocks spread all over the place. Unintelligible for the most part. One of the PDP-11 projects I ran across used this approach. Writing code down at the LUT level... Ugly!I haven't done it recently but I like microcoding as in the old 2102 days. All of the logic is contained in a ROM (BlockRAM) and each address results in certain signals being tickled. Load a register, test and branch, things like that. With this approach, the entire microcode can be built outside the FPGA and simply stuffed into the BlockRAM at startup. The result is usually a very clean machine design. I'm going to try that next time. Write the meta-assembler in Python and have it generate code for 'dat2mem'. This could actually work! Design the data path and do the control code elsewhere.But it's still a state machine...

author: nctnico
author_rank: Super Contributor
timestamp: August 13, 2016, 06:16:20 pm
content: When it comes to statemachines the first thing to do is to realise that you are making a statemachine. Too often you'll see code like 'if a=1 and b=5 then do X else if b=2 and c=2 then do Y' which is just a big stinking pile of unmaintainable sh*t.BTW In VHDL you can make enumeration types which leave the synthesizer total freedom to choose between any statemachine encoding it likes. A VHDL statement likeCode:state_number <= to_unsigned(Esys_state'pos(sys_state), state_number'length);can be used to convert the encoded state into a number for reading it back to debug.@rstofer: I used something similar over a decade ago for a design which needed to do various operations on samples for a number of channels. My colleague and I came up with a bidirectional bus (supported in Xilinx Spartan2) to which all input and outputs of the ADC interface and processing modules where connected and used Perl to generate the blockram data which was used as a 'microcode' program.

author: rstofer
author_rank: Super Contributor
timestamp: August 13, 2016, 06:49:55 pm
content: Back in the mid '70s, I designed the CPU for the IBM 1130 using microcode stored in blown-link PROMs. It was a really fun project! At the time, RAM wasn't readily available for hobbyists and all I could get was dynamic so I never finished that project. The microcode was all done on punch cards, listed and then transferred into manually blowing links.Fast forward to early '00s and I finally built the machine in an FPGA; I have had a 46 year love affair with that machine. First computer and all...One of the neat things about microcode is that it allows for 'stepwise refinement' without rebuilding the VHDL. I suspect this would be truly useful when trying to implement really complex things like floating point and trig functions. Even non-restoring signed division would be a lot easier to write in a meta-assembler than in VHDL.What I don't know is how to define the data path such that it remains constant as more functionality is added. Sure, there may need to be small changes but I would like the main register transfer and ALU pieces to remain fixed. That implies I could define them correctly in the first place - not a good bet, I fear...

author: ehughes
author_rank: Frequent Contributor
timestamp: August 14, 2016, 04:04:06 am
content: http://www.bawankule.com/verilogcenter/contest.htmlIn most real world scenarios, Verilog wins.Verilog was created by 2 guys working in the industry to solve a real world problem.VHDL was the result of government and academia trying to come up with the end all modeling language.Design by committee languages often end up ridiculously fluffed.When it takes 3x the code to get the same functionality, VHDL ends up as an unreadable mess for large designs.Once you get past FPGAs and move to ASICs, it is overwhelmingly Verilog (Cadence owns Verilog and is a huge player in the ASIC world)

author: scatha
author_rank: Regular Contributor
timestamp: August 14, 2016, 05:29:39 am
content: Quote from: ehughes on August 14, 2016, 04:04:06 amI don't see how that link constitutes a 'real world scenario' - it's from 1997 and based on a toy problem.To claim a 3x overhead for VHDL is hyperbole - *maybe* if you were to maximise the number of small design units and then used the most verbose form of component instantiation, but in larger design units the LoC difference is small. I've certainly been subjected to more 'unreadable mess' Verilog projects than VHDL based-ones, to the point where I actively dread the language. Maybe things are different in ASIC land, but that's not a space I play in.

author: nctnico
author_rank: Super Contributor
timestamp: August 14, 2016, 09:30:28 am
content: Quote from: ehughes on August 14, 2016, 04:04:06 amIf you think in logic and want to create a netlist then Verilog is the right tool. Verilog code looks exactly like a netlist to me. However I think I'd be done in 30 minutes to create the design requested by the contest with a few lines of VHDL and then tweak the synthesizer options to optimise the end result. VHDL versus Verilog starts to sound like an assembly versus C discussion.

author: Cerebus
author_rank: Super Contributor
timestamp: August 14, 2016, 05:28:54 pm
content: Quote from: nctnico on August 14, 2016, 09:30:28 amWell, C and assembler are essentially the same thing. C is just an assembler that's non machine specific and somewhat less programmer hostile than most assemblers. No bounds checking (almost universal in other common HLLs at the time of C's inception), ability to freely switch between any interpretation of a string of bits as an integer or a pointer or a character, register variables, #define, #ifdef - classic macro assembler, the 'for' loop that looks like nothing more than an assembler macro etc. etc. To anybody who knows PDP-11 assembler (which was the original target for the K&R compiler) it's blindingly obvious where (++i) and (i++) came from - the C expression (a = *b++) compiles into a single instruction on a PDP-11; in fact I think even (*--a = *b++) would be a single instruction on a PDP-11 but honestly I'd have to check that particular expression.C is, and always has been, a fancy assembler on steroids - that is its strength and its weakness.

author: zapta
author_rank: Super Contributor
timestamp: August 14, 2016, 06:32:50 pm
content: Quote from: nctnico on August 13, 2016, 06:16:20 pmFew years ago I needed to program a FPGA for the first time. When I shawn my initial code to a colleague with HDL experience, he gave me a good advice: "avoid 'if' statements, use conditional expressions instead".Something along these lines:my_signal <= condition1 ? value1:condition2 ? value2:...default_value;That made VHDL programming much easier for me, eliminating the complexity of multiple assignments per signal. This rule applied to all signals, not only state machines (where my_signal depends on itself).

author: helius
author_rank: Super Contributor
timestamp: August 14, 2016, 07:37:19 pm
content: Quote from: Cerebus on August 14, 2016, 05:28:54 pmThis violates the weak aliasing rule present in every version of ANSI and ISO C.Qualifiers likeconstorrestrict, variable-length arrays, and complex numbers, are also without any corresponding construct in assembly language.These changes are part of a much wider shift in compiler technology, that means assembly programs are poorly optimized in comparison with compiled programs. A backward "assembler on steroids" is no longer relevant, and today's C doesn't fit that description. C programs that depend on being compiled into instructions just like they are written no longer work with today's compilers.

author: Cerebus
author_rank: Super Contributor
timestamp: August 14, 2016, 10:59:00 pm
content: Quote from: helius on August 14, 2016, 07:37:19 pmStill true though, vis:Code:void junk(){char *aBuffer;unsigned long int aNumber;aNumber = (unsigned long int) aBuffer;aBuffer = (char) aNumber;}That compiles in C99 without even a warning. A properly typed programming language wouldn't let me do that. An overgrown assembler would.QuoteTo be precise, those changes have nothing to do with compiler technology. They are changes in the language definition and could have easily been compiled with the same level of compiler technology as K&R C was. I'd strongly dispute your second assertion; with the exception of instruction sets that make extensive use of delay slots and similar hardware optimization techniques - a compiler will nearly always do a better job with those than a human.QuoteOf course it's relevant, it's called embedded and systems programming. C is used for that because of its ability to get close enough to the hardware that twiddling bits in registers in predictable fashion.And of course modern C isn't an "assembler on steroids", it's an overgrown assembler on steroids. I'm messing with you here. C needed revising if it was going to continue to be used outside its original target environment but really it ought not have been and better programming languages ought to have become widespread instead.QuoteI don't believe I said or implied anything like that. The nearness of the PDP-11 pre and post increment and decrement instructions and the C equivalents are just evidence of its quintessential nature, not an advocacy of that as a programming style. At any time with any compiler, any (non systems) code that depends on being compiled into particular explicit instructions should be immediately put into the bin.My opinion stands. And it's just that, an opinion, but based on 40 years programming in literally dozens of different programming languages on dozens of different architectures. I've worked as a systems programmer ferreting about on the insides of operating systems and as a compiler writer writing code generators. My programming days pre-date the existence of C outside of the Bell Labs community. Prior to C, I spent many tedious hours writing assembler because there was no other way to get close enough to the hardware. Post C, I've been able to do those same tasks, sometimes quite portably, in C. That I have substituted C for assembler is pretty strong evidence of its basic nature.

author: hamster_nz
author_rank: Super Contributor
timestamp: August 15, 2016, 12:16:53 am
content: I am quite fond of C being so light-weight a language - and that you can build whatever you want on top of it's minimal library functions.On big projects where issues slowly creep in I've added in my own safe-guards (like heap corruption detection, and data type verification) that disappears when _DEBUG isn't defined. It really isn't that hard - make a "safe_malloc(site_t size, unsigned data_type_magic)" that actually allocates a little more memory than needed and store a little metadata in the extra space.You can then:* verify that memory space hasn't been blown out - check the known value at the end* verify that the pointer has been allocated to be the type expected - check the type value* verify that you have allocated enough space - check the size value in the start* verify that all allocated space gets free()edIf you are really fussy you can have the C compiler include the file name and line number (have the preprocessor include __FILE__ and __LINE__ on the safe_malloc() call) so it can tell you where memory was allocated.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 15, 2016, 07:02:44 am
content: Quote from: Cerebus on August 14, 2016, 10:59:00 pmBut the use of casting implies you know what you're doing - even the best-designed language can fail if people abuse it.I'm sure it would have given warning is the casing wasn't there.

author: nctnico
author_rank: Super Contributor
timestamp: August 15, 2016, 07:26:50 am
content: Quote from: mikeselectricstuff on August 15, 2016, 07:02:44 amSame here. Even in VHDL you can cast some types into another but without such a cast it won't 'compile'.

author: Cerebus
author_rank: Super Contributor
timestamp: August 15, 2016, 04:25:59 pm
content: Can we get back on topic please? Y'know, Verilog, VHDL.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 15, 2016, 05:17:40 pm
content: Quote from: rstofer on August 13, 2016, 05:01:16 pmYes, you need "memory" to build sequential circuits, but not always a full-blown state machine (with, for example, the two-process approach which you mention). Not everything is complex enough to require an FSM.Here's an example: I recently implemented a simple serial port in Verilog, first as a full-blown state machine, and then as a much simpler non-FSM model.Code:`timescale 1ns / 1psmodule serial#(parameter TBIT=868, // bit time in 100 MHz clocks for 115,200 baud)(input logic clk,input logic rst,input logic start,input logic [7:0] din,output logic [7:0] dout,output logic dataready,output logic txbusy,input logic RX,output logic TX);enum logic [2:0] {TXIDLE, TXSTARTBIT, SEND1, SEND2, TXSTOP} txstate, next_txstate;enum logic [2:0] {RXIDLE, RXSTARTBIT, RECEIVE1, RECEIVE2, RXSTOP} rxstate, next_rxstate;logic [11:0] txtimer, rxtimer;logic [7:0] data, data_next;logic [7:0] rdata, rdata_next;logic [3:0] bits, bits_next;logic [3:0] rbits, rbits_next;logic [11:0] txcount, rxcount;logic rx1, rx2;// Transmitalways_ff @(posedge clk, posedge rst) beginif (rst) begintxcount <= 0;txstate <= TXIDLE;endelse beginbits <= bits_next;data <= data_next;txcount <= txcount + 1;if (txcount >= txtimer) begintxstate <= next_txstate;txcount <= 0;endendendalways_comb beginbits_next = bits;case (txstate)TXIDLE: begintxtimer = 1;data_next = din;TX = 1'b1;bits_next = 8;if (start == 1'b1)next_txstate = TXSTARTBIT;elsenext_txstate = TXIDLE;endTXSTARTBIT: begintxtimer = TBIT;data_next = din;TX = 1'b0;next_txstate = SEND1;endSEND1: begindata_next = data;TX = data;txtimer = TBIT;next_txstate = SEND2;endSEND2: begintxtimer = 0;TX = data;data_next = {1'b0, data[7:1]};bits_next = bits - 1;if (bits == 1) begintxtimer = 0;next_txstate = TXSTOP;endelse beginnext_txstate = SEND1;endendTXSTOP: beginTX = 1'b1;txtimer = TBIT;data_next = din;next_txstate = TXIDLE;enddefault: begintxtimer = 1;TX = 1'b1;data_next = din;next_txstate = TXIDLE;endendcaseend// Receivealways_ff @(posedge clk, posedge rst) beginif (rst) beginrxcount <= 0;rdata <= 0;rxstate <= RXIDLE;endelse beginrx1 <= RX;rx2 <= rx1;rbits <= rbits_next;rdata <= rdata_next;rxcount <= rxcount + 1;if (rxcount >= rxtimer) beginrxstate <= next_rxstate;rxcount <= 0;endendendalways_comb beginrbits_next = rbits;rdata_next = rdata;case (rxstate)RXIDLE: beginrxtimer = 0;if (rx2 == 1'b0) // start bitnext_rxstate = RXSTARTBIT;elsenext_rxstate = RXIDLE;endRXSTARTBIT: beginrxtimer = TBIT/2 - 1; // 1/2 bit timerbits_next = 7;next_rxstate = RECEIVE1;endRECEIVE1: beginrxtimer = TBIT - 2;next_rxstate = RECEIVE2;endRECEIVE2: beginrxtimer = 0;rdata_next = {rx2, rdata[7:1]};rbits_next = rbits - 1;if (rbits == 0) beginrxtimer = 0;next_rxstate = RXSTOP;endelsenext_rxstate = RECEIVE1;endRXSTOP: beginrxtimer = TBIT - 2;next_rxstate = RXIDLE;enddefault: beginrxtimer = 1;next_rxstate = RXIDLE;endendcaseendassign dout = rdata;assign dataready = (rxstate == RXSTOP);assign txbusy = (txstate != TXIDLE);endmoduleCode:`timescale 1ns / 1psmodule serial#(parameter TBIT=10 // bit time in 100 MHz clocks for 115,200 baud)(input logic clk,input logic rst,input logic start,input logic [7:0] din,output logic [7:0] dout,output logic dataready,output logic txbusy,input logic RX,output logic TX);// Transmitlogic tx_started;logic [9:0] tdata;logic [3:0] tbits = 0;logic [11:0] tcounter;always_ff @(posedge clk) beginif (start) begintcounter <= TBIT - 1;tdata <= {1'b1, din, 1'b0};tbits <= 0;tx_started <= 1;endelse if (tx_started) beginTX <= tdata;tcounter <= tcounter - 1;if (tcounter == 0) begintcounter <= TBIT - 1;tbits <= tbits + 1;tdata = {1'b0, tdata[9:1]};if (tbits == 9)tx_started <= 0;endendendassign txbusy = tx_started;// Receivelogic rx_start;logic rx_started = 0;logic [7:0] rdata;logic [3:0] rbits = 0;logic [11:0] rcounter;logic [2:0] rxd = 3'b0;// synchronize to the incoming RX data line using a 3-bit shift registeralways_ff @(posedge clk) beginrxd <= {rxd[1:0], RX};endassign rx_posedge = (rxd[2:1] == 2'b01); // positive edge on the RX lineassign rx_negedge = (rxd[2:1] == 2'b10); // negative edge on the RX lineassign rx_start = (rx_negedge && ~rx_started); // start bit detectedalways_ff @(posedge clk) beginif (rx_start) beginrcounter <= TBIT/2 - 1;rdata <= 8'b0;rbits <= 0;rx_started <= 1;endelse if (rx_started) beginrcounter <= rcounter - 1;if (rcounter == 0) beginrdata <= {rxd, rdata[7:1]};rcounter <= TBIT - 1;rbits <= rbits + 1;if (rbits == 8)rx_started <= 0;endendendassign dout = rdata;assign dataready = ~rx_started;endmodule

author: nctnico
author_rank: Super Contributor
timestamp: August 15, 2016, 05:25:53 pm
content: Again: what often helps is to make a flowchart on paper first. This usually shows which states are irrelevant and/or can be combined.

author: Kilrah
author_rank: Unknown
timestamp: August 15, 2016, 06:02:53 pm
content: I don't consider these being "making a state machine" or "not making a state machine", it's just different levels of optimization (more as source code amount than in resources) / expression of the same state machine.Yes when you have to send 10 bits you can have an idle state and 10 "bitX" states, or you could only have one "running" flag and use a bit counter to know where you are... both are state machines just as much, they simply use a more or less explicit way to express it.

author: Muxr
author_rank: Super Contributor
timestamp: August 15, 2016, 06:12:59 pm
content: My fulltime job is a programmer (distributed systems not embedded). When I got into FPGA for hobby purposes I looked at the syntax and liked Verilog better.. so I've been using Verilog

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 15, 2016, 06:21:40 pm
content: Quote from: Kilrah on August 15, 2016, 06:02:53 pmMy point wasn't directed towards what you call these things, but that sometimes a more formal description of a problem is overkill and a simpler approach is not only more readable, but more likely to correct by inspection.

author: legacy
author_rank: Super Contributor
timestamp: August 15, 2016, 07:48:36 pm
content: Code:type state_t is(s_idle_w,s_idle_r,s_start_w,s_start_r,s_data0_w,s_data0_r,s_data1_w,s_data1_r,s_data2_w,s_data2_r,s_data3_w,s_data3_r,s_data4_w,s_data4_r,s_data5_w,s_data5_r,s_data6_w,s_data6_r,s_data7_w,s_data7_r,s_stop_w,s_stop_r);well, on the psx_pad ... data_out is written on the falling edgewhereas the data_in is read on the rising edgethat means that, in the theory, you need both the edge types {falling edge, rising edge}but you can't have both the logic on your fpga's project, you have to choose, it's mutually exclusivepersonally i prefer "rising_edge", therefore I am using the following trickCode:-- pad clockprocess(in_clock,in_reset,state_curr)beginif (in_reset = '1') thenpad_out_clk <= '1';elsif rising_edge(in_clock) thencase state_curr is------------------------------when s_data0_w =>pad_out_clk <= '0';when s_data0_r =>pad_out_clk <= '1';_w stands for write data_out on falling edge_r stands for read data_in on rising edgetherefore it actually reads date on rising edge, whereas it writes data on falling edgeCode:constant tick : integer := (clk_freq/baudrate);the psx_pad's baudrate needs to be 250Khz, while clk_freq can be 50Mhz, so, since clk_freq < 2 * baudrate, the finite state machine can evolve its state_next at the *double speed* (that is the limitation of this method), and this permits to have the full control of both rising_edge and falling_edge (including delays)Code:--fsm state_nextprocess(in_clock,in_reset,state_curr)beginif (in_reset = '1') thenstate_next <= s_idle_w;elsif rising_edge(in_clock) thenif (tick_counter = tick-1) thencase state_curr is------------------------------when s_idle_w =>state_next <= s_idle_r;when s_idle_r =>if (write_en = '1') thenstate_next <= s_start_w;elsestate_next <= s_idle_w;end if;------------------------------when s_start_w =>state_next <= s_start_r;when s_start_r =>state_next <= s_data0_w;------------------------------when s_data0_w =>state_next <= s_data0_r;when s_data0_r =>state_next <= s_data1_w;it's not elegant and compact, it eats resources, but I am satisfied by the result

author: whollender
author_rank: Regular Contributor
timestamp: August 15, 2016, 09:31:03 pm
content: Quote from: legacy on August 15, 2016, 07:48:36 pmYou can actually use both, at least on Xilinx Spartan 6 using ISE 14.7. I would assume that newer Xilinx devices also support both rising and falling edge clocks. The only constraint is that all logic in a slice must use the same edge type, but you can use both on a single device.

author: legacy
author_rank: Super Contributor
timestamp: August 15, 2016, 09:54:24 pm
content: Quote from: whollender on August 15, 2016, 09:31:03 pmif all logic in a slice *MUST* use the same edge type it means you have to *choose the edge type*, and you can't use both types in your project, that is exactly what made me to think about the trickhere I am on Spartan3E, ISE v10.1, and it claims errors if i try to do so (if i try to have both edge types in a single slice), whereas it's perfectly fine for ghdl, but ghdl doesn't have to fit to real hardware, therefore I can have both edge types only in RTL simulation.

author: whollender
author_rank: Regular Contributor
timestamp: August 15, 2016, 10:06:07 pm
content: Quote from: legacy on August 15, 2016, 09:54:24 pmIt does look like the Spartan3E CLBs are missing the inverter and mux on the clock input that the Spartan6 CLBs have.On a Spartan6, code like this works just fine:Code:shift_in: process (BCLK)beginif rising_edge(BCLK) thenshiftreg_in <= shiftreg_in(shiftreg_in'high-1 downto 0) & I2S_DATA_IN;end if;end process;shift_out: process (BCLK)beginif falling_edge(BCLK) thenif fs_str = '1' thenshiftreg_out <= data_reg_out;elseshiftreg_out <= shiftreg_out(shiftreg_out'high-1 downto 0) & '0';end if;end if;end process;That way you don't absolutely need to have a double rate clock for doing that type of shift register work.

author: Cerebus
author_rank: Super Contributor
timestamp: August 15, 2016, 11:25:29 pm
content: Quote from: whollender on August 15, 2016, 10:06:07 pmI have vague memories from some years back of being forced to use a multiphasic clock on a Spartan 3 when I'd originally coded for using both clock edges. It was actually a blessing in disguise as I then came up with a much tidier design using 4 clock phases.

author: Buriedcode
author_rank: Super Contributor
timestamp: August 16, 2016, 12:04:03 am
content: Quote from: ataradov on August 12, 2016, 03:36:42 pmBeat me to it. State machines are much easier with it.I can't say I have much experience (like 3 *working* projects?) but had to translate some VHDL to verilog and I realized that I can actually sit down and type verilog that makes sense to me - without having to stop every 5 minutes to google something - it makes sense, but as many have said, C-like yes, but of course - its a HDL, not software.I had to learn VHDL at university, and I have used it here and there. I don't like writing it at all, its an arse and takes *me* a long time to write any module. But the plus is, once the design software stops pointing out errors - it generally works exactly as intended. Where-as verilog, I usually have to verify with a logic analyzer and seemingly endeless simulations, even then it often doesn't do what I intended first time. So really both have their place, for reliability and if you were going to do it for a job, I would learn VHDL (having to actually do that now..).

author: legacy
author_rank: Super Contributor
timestamp: August 16, 2016, 07:03:50 am
content: even if I can use a spartan6 board like the papilio/pro, I have legacy reasons to support spartam3e boards,using both clock edges seems a blessing in disguise (a false blessing), especially if the playstation's pad uses a long cable (~half meters between the pad and the controller), spi doesn't work well with long cables, and you come into troubles if you don't provide extra sample & holdin the simulation the fpga clock is 50Mhz, the psx_pad clock is 12.5MHznote the delay between psx_pad's clock and psx_pad's cmd (data out)

author: legacy
author_rank: Super Contributor
timestamp: August 16, 2016, 08:27:49 am
content: main reasons to use vhdl: tools!I don't feel comfortable with verilog's tools, whereas ghdl has offered the opportunity to develop the following building tool, it's written in C under linux, it's a project I have developed to boost my productivity, and it's fineCode:# cat project.list.myprj../../rtl/package../../rtl/bus-mm../../rtl/bus-mm-controller-sram-asynchronous../../rtl/controller-sram-asynchronous./define sourcesCode:# cat project.analysis.myprjmeasure bus_clocktime_lapse dtackdefine what you want to observe from the RTL simulationCode:# cat project.time.myprj100usdefine simulation timeCode:# myghdl-build-project-makefile-v6once all of the above has been defined, the tool automatically builds the MakefileCode:# myghdl-build-project-makefile-v6[*] ../../rtl/package[*] ../../rtl/bus-mm[[bus_mm_alignment.interface]]bus_mm_alignment[bus_mm.def][[bus_mm_device.interface]][[bus_mm_device_sel.interface]]bus_mm_device_selbus_mm_device[[bus_mm.interface]][[bus_mm_size_mask.interface]]bus_mm_size_maskbus_mmstage_load_store[*] ../../rtl/bus-mm-controller-sram-asynchronous[[bus_mm_controller_sram_asynchronous.interface]]bus_mm_controller_sram_asynchronous[*] ../../rtl/controller-sram-asynchronous[[controller_sram_asynchronous.interface]]controller_sram_asynchronous[*] ./tb_my#packages are handled as "definitions", components are handled as "interfaces", everything else is handled as "behavioral implementation", this tool is able to resolve the dependency tree, in order to allow to compile without errors. ghdl needs some external work, whereas Xilinx ISE is also able to do the same without any external help, I like ISE, I don't like iSimCode:co-nix arise-v2-bus-mm # makecompiling bus_mm.def ... donecompiling controller_sram_asynchronous.def ... donecompiling +definitions ... donecompiling bus_mm_alignment.interface ... donecompiling bus_mm_device.interface ... donecompiling bus_mm_device_sel.interface ... donecompiling bus_mm.interface.interface ... donecompiling bus_mm_size_mask.interface ... donecompiling controller_sram_asynchronous.interface ... donecompiling stage_load_store.interface ... donecompiling +interfaces ... donecompiling bus_mm_alignment ... donecompiling bus_mm_controller_sram_asynchronous ... donecompiling bus_mm_device_sel ... donecompiling bus_mm_device ... donecompiling bus_mm_size_mask ... donecompiling bus_mm ... donecompiling stage_load_store ... donecompiling controller_sram_asynchronous ... donecompiling tb_my ... donecompiling +behaviorals ... donerunning simulation ... done, see report.txtrunning analysis ... done, see analysis.txta gtkwave file (tbencha.ghw) is now available with time details, while analysis.txt contains a lot of useful information, e.g. time/frequency reportCode:..bus_clock: 40000000 fs, 25000000 Hzdtack: 120000000 fs..Code:# make viewit launches gtkviewalso I am usingthisvhdl-helper, it's a collection of useful functions which help me a lot with the test bench activityI don't yet have a similar ecosystem (tools and helpers) with verilog, not yetedit:I have also developed other tools which help me to create the test-bench and interfaces, it partially understands vhdl, the parser doesn't understand the whole vhdl grammar, just a subset, anyway it's enough to extract entities, build components, etc etc. it's not like Sigase, but it's fine for me, and it doesn't cost a license.

author: nctnico
author_rank: Super Contributor
timestamp: August 16, 2016, 08:58:15 am
content: I use the Eclipse and the (free) veditor plugin to write VHDL because it is 1000 times better than the crummy editor in ISE. Veditor is not perfect yet when it comes to cross referencing type declarations and syntax checking but it already makes life a whole lot easier.

author: legacy
author_rank: Super Contributor
timestamp: August 16, 2016, 10:15:54 am
content: Quote from: nctnico on August 16, 2016, 08:58:15 amat the beginning I was interested because enthusiast of such of tools and IDE, after a very bad job experience withWindriverand theirWorkbench(which is based on Eclipse) my feelings changed and now Ihatethose hyper complex tools, and this is the main reason why I wrote my own tool: with Eclipse I have always been doomed with metafiles and other stuff, not mentioning that those tools (Eclipse and something that is based on its source) are also too slow on my laptop(1)with "too slow" I means that it makes me annoyed, delays are in order of secondsand, in my experiences, when it failed with metadata ... I lost the whole project, wasting a lot of time to figure out what was wrong without finding an answer, therefore the only solution I found was a brutal "erase and rewind"delete the whole project (except source files)click on "new project", attach source files, and start to describe it from the scratchQuote from: nctnico on August 16, 2016, 08:58:15 amISE looks very comfortable once integrated withScriptumby HDL Works (there is a freeware edition)it's a pure HDL editor with syntax highlighting, no other special features (unless you buy the full version)anyway it's very comfortable, and it's able to track the line error if used with ISEghdl is still missing a good error report engine (on Sigasi's blog people also reported the same comment about it), sometimes it's not clear *WHAT* is wrong and *WHERE*, but you can ask ISE to give you an hand, ISE's checker (syntax and semantic) can be set to be very fussy, which is usefuland in case of error it invokesScriptumwhich is able to track me back to the code's line(1) WindowsXP/32bit +CoNix, cooperative unix under Windows, running gentoo/x86hw specifications, intel i2@1.6Ghz, with 2Gbyte of ram

author: legacy
author_rank: Super Contributor
timestamp: August 16, 2016, 12:54:36 pm
content: verilog booksI was given a gift, it's an old book (1st Edition, more than 10 years old),Real World FPGA Design with Verilogby Ken Coffman (Author)my impression? From a preliminary read it seems that it needs tune up since it's based on old technology, anyway it looks teaching real world trips and tricks, and hey? it's a free gift, and those things are always welcome, oh, and it comes with a CD, it includes a few trial tools, whereas it doesn't tell a word about alternative tools likeicarus(probably because icarus was not mature/usable when the author wrote the book)

author: gauravmp
author_rank: Regular Contributor
timestamp: August 17, 2016, 05:48:26 pm
content: There is a saying for VHDL: Very Hard Description Language.Verilog is very intuitive and doesn't require one to remember a lot of syntaxes so I use Verilog.

author: free_electron
author_rank: Super Contributor
timestamp: August 17, 2016, 07:37:25 pm
content: systemverilog 2005. hands down- less keyboard pounding ( especially all the boilerplate junk you need to replicate in each and every file with vhdl )- no stupid 2 times declaration of every single signal ( once in module header, once in signal type)- can use output signals immediately ( contrary to vhdl )- constructs like always_ff , always_comb , always_latchthis results in much higher productivity.

author: rstofer
author_rank: Super Contributor
timestamp: August 17, 2016, 08:10:47 pm
content: Quote from: gauravmp on August 17, 2016, 05:48:26 pmEverybody keeps saying all that neat stuff about Verilog. How come I just don't 'get it'? Seriously, I have made several attempts to get started with Verilog and every time I just started over in VHDL. Maybe it's just old age...

author: photon
author_rank: Frequent Contributor
timestamp: August 17, 2016, 11:53:31 pm
content: Quote from: rstofer on August 17, 2016, 08:10:47 pmIf you asked specific questions about what you find hard to understand in verilog, I bet you'll get good answers on this board.

author: rstofer
author_rank: Super Contributor
timestamp: August 18, 2016, 03:56:49 am
content: Quote from: photon on August 17, 2016, 11:53:31 pmNo doubt!I have a few reasons why I don't like the syntax and that is probably the real reason I don't put in the effort to learn the language. In the end, both languages describe the same hardware and there are only so many constructs. And there's no need to learn the language because a) VHDL works fine and b) I'm not looking for a job. Retirement is excellent!

author: legacy
author_rank: Super Contributor
timestamp: August 18, 2016, 08:28:30 am
content: my problems with vhdl:buffer <- it might cause a lot of problems with hierarchical designs, according to Xilinx App Notes you'd better avoid to use it, they say it might cause problems with the synthesizerout <- due to strange limitation in vhdl, you can't read back signals once defined as "out"inout <- it's not a real problem but it needs some workssolutionsbuffer <- I don't use it, never, it's a banned keyword in my vhdl dictionaryout <- I define a local signal inside my modules, and assign it to the "out", this solutions costs a few more logic gates, but it's fineinout <- I define the behavior for the high impedance, it's just a few line of code, don't use it to pass information through sub-modules, therefore I use "inout" only at the top-module because I have to route it to physical constraints (mapped pins)

author: rstofer
author_rank: Super Contributor
timestamp: August 18, 2016, 02:11:16 pm
content: Quote from: legacy on August 18, 2016, 08:28:30 amAll true!i also use the approach of defining an internal version of an output signal I want to read back. I don't know that it actually generates more logic. But, yes, it's a PITA.I have used inout but not all that often. Further, I'm not sure that FPGAs like the idea of tri-state buses. They seem to prefer muxes.OK, here's my issue with Verilog:I first list a signal name in the module definition. Some time later, I declare it as input or output and some time after that I have to refine the definition if it is registered. I have to write 3 different definitions, in three different lines of code to replace a single line of code in VHDL. Looking at the module definition only, I can't even tell which signals are inputs or output and I can't determine whether they are a single signal or a logic vector. I have to scan farther down the page to figure it out.And what's this 'wire' vs 'reg' thing all about? If a signal is set in a clocked process, it is a register. If it is set in a combinatorial process it is a wire. There's no need to get all pedantic about defining the signal, it's just a signal.I still haven't sorted out 'blocking' vs 'non-blocking'. Again, if a signal is set in a clocked process, it is registered and it's value changes on a clock edge. If it is set outside of a clocked process, it is not registered and it's value changes when the other logic levels change and the change is not synchronized. "assign"? Why go through these push-ups?I also prefer the module instantiation syntax of VHDL over Verilog. I like the more tabular arrangement. Yes, I could come up with a pretty way to instantiate a Verilog module but, more often than not, I see something like:Code:module dff (clk, d, q);input clk, d;output q;reg q;always @(posedge clk) q = d;endmodulemodule top;reg data, clock;wire q_out, net_1;dff inst_1 (.d(data), .q(net_1), .clk(clock));dff inst_2 (.clk(clock), .d(net_1), .q(q_out));endmoduleIn any event, it's really a matter of preference. Neither language can 'invent' new features in the logic matrix. Both describe exactly the same logic. It's just a matter of syntax.

author: Cerebus
author_rank: Super Contributor
timestamp: August 18, 2016, 03:20:34 pm
content: Quote from: rstofer on August 18, 2016, 02:11:16 pmYou don't, not since (I think) Verilog 1995. Your version:Code:module dff (clk, d, q);input clk, d;output q;reg q;always @(posedge clk) q = d;endmodulecan be much more succinctly written as:Code:module dff (input clk, d, output reg q);always @(posedge clk) q = d;endmodule

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 18, 2016, 04:14:55 pm
content: Quote from: rstofer on August 18, 2016, 02:11:16 pmSystemVerilog has a new type called "logic" that can replace both wire and reg. You can use it interchangeably for both and no longer need to worry about whether you're defining combinatorial logic or sequential logic. SystemVerilog merged with Verilog in 2009 and now SystemVerilog and Verilog are the same thing. Verilog now supports enums, structs/unions, interfaces, and a bunch of other stuff.Not liking Verilog based on some ancient definition of the language is not logical.

author: rstofer
author_rank: Super Contributor
timestamp: August 18, 2016, 08:04:46 pm
content: Quote from: Cerebus on August 18, 2016, 03:20:34 pmAnd that's the problem with books and the Internet. It is pretty easy to find archaic ways to use a language and not pick up on the far superior syntax of the more advanced revision.I didn't invent that example, I just Googled for 'Verilog module declaration', found a web page and went down the TOC to module instantiation:http://verilog.renerta.com/source/vrg00027.htmI could deal with the revised syntax - everything is in one place. Thanks!

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: August 18, 2016, 08:40:53 pm
content: Quote from: rstofer on August 18, 2016, 08:04:46 pmYep, that's a big problem, especially for beginners who aren't aware of the changes.You can't blame the language itself, however. You just need to be able to differentiate the old from the new, which, without clues, can be difficult. Kind of like someone who doesn't know English well Googling "English Poetry" and coming up with the Canterbury Tales and thinking it's representative of modern English.

author: rstofer
author_rank: Super Contributor
timestamp: August 18, 2016, 08:56:18 pm
content: Quote from: Sal Ammoniac on August 18, 2016, 08:40:53 pmIt's a big enough problem, when comparing Verilog to VHDL, for my purposes, to just kiss off Verilog as obscure or difficult.Then too, there is often a huge disconnect between old and new. There is very little similarity between FORTRAN IV and whatever we call it today (FORTRAN 95?). Learning with version IV was pretty easy. I'm not so sure about the new version. Yes, the changes were necessary to keep up with people's expectations of a programming language for a modern computer but they definitely increase the height and slope of the learning curve.

author: legacy
author_rank: Super Contributor
timestamp: August 18, 2016, 09:36:15 pm
content: Quote from: rstofer on August 18, 2016, 03:56:49 amI like ADA, I am a freelancer working in the avionics's field, a few months ago I was contacted by some dudes in nuclear physics (gamma-gamma experiments(1)) field because they needed someone with some skill in vhdl and fault tolerant techniques in order to provide some "radiation hardening" tricks to their equipmentI am afraid that I am not the right dude, I don't have skills in physics, even my skills with vhdl are not brilliant, still under the supervision of those experts in the specific fields, we have been implementing a lot of R-H-tricks since the first meeting, oh and my personal part of fun is that ... I am using a lot of optical fiber patches, and I like to put my hands on lasers and optical detectorsanyway, I am located in Europe:do you think I'd better learn Verilog?Since I am ADA addicted (due to my job in avionics and personal mind set, pascal was my first language, before C/C++) I find vhdl more closed to my mindtherefore I have *a lot* of difficulties with verilog, and ... I am afraid that knowing just one HDL language might be a problem in the near future for the industry(1) as far as I understood they are studying what happens when two gamma ray photons collide together, it seems you have something like the followingmass-less waves, photons --> collision, something happens --> massive particles arise upI don't know about details, but I know that during the collision there is *a lot* of radiation propagation around the digital equipment which collects and transmits data from the sensor array, and some electrons which are flowing through their electronic-circuits might be affected by the radiation which can cause to turn over with a sudden sharp movement resulting some bits to toggle randomly, and we can't avoid it to happen, we can just avoid to read wrong information, we have some techniques to do so, e.g. implementing devices with hamming encoding and decoding

author: rstofer
author_rank: Super Contributor
timestamp: August 18, 2016, 09:57:48 pm
content: Learning Verilog...Yes, I think you should take it up. BTW, I'm starting to play with Ada and struggling with AdaCore and it's apparent total lack of documentation. I just want to use the SPI gadget, not write a revision of "War and Peace". I digress...In the end, there are only a few constructs that get created by any HDL. Logic equations (AND, OR, NOT, etc), register/counter, multiplier, ALU, MUX, decoder, priority encoder and state machine. I may have missed a couple... So, get a book that covers the latest version of the language and learn to implement these gadgets. Everything else is details. Check the RTL to see what gets synthesized for various implementations of the fundamental blocks. Alternate codings will produce somewhat different logic.I have also seen code directed straight at the LUT. This code tends to be highly optimized but certainly non-portable. I don't know what I think about that... Nevertheless, different chips will probably have different ways to implement the various gadgets as a function of the LUT design. Worth knowing about...

author: legacy
author_rank: Super Contributor
timestamp: August 21, 2016, 11:39:18 am
content: it seems that VHDL wins in the both hobbyist and pro fields

author: Someone
author_rank: Super Contributor
timestamp: August 22, 2016, 12:02:21 am
content: Quote from: legacy on August 21, 2016, 11:39:18 amIts a matter of style without a clear winner. I can only think of a few minor things which can only be done in VHDL and cannot in Verilog (but they might be important to you!) while many simple things in Verilog require verbose casting or assignment in VHDL. It really depends how you see it, the strict casting and control flows of VHDL can enforce "better" design, or they can pollute a simple module with distractions from the underlying function.VHDL 2008 advances a few of the bigger stumbling blocks:https://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_ease/But there will still be a need for writing and including clumsy type casting functions:http://www.ics.uci.edu/~jmoorkan/vhdlref/typeconv.html

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2016, 09:26:44 am
content: Quote from: Someone on August 22, 2016, 12:02:21 amthat's a +1 in my VHDL choice

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2016, 09:30:29 am
content: I'd like to learn and use verilog, in order to do so I need a tool similar to ghdl, and the following seems perfectCode:* sci-electronics/iverilogLatest version available: 0.9.6Latest version installed: 0.9.6Size of files: 1,192 KiBHomepage: http://iverilog.icarus.com/Description: A Verilog simulation and synthesis toolLicense: GPL-2

author: nctnico
author_rank: Super Contributor
timestamp: August 22, 2016, 09:44:57 am
content: Quote from: Someone on August 22, 2016, 12:02:21 amOne of the biggest problems I see with people writing VHDL is that they use std_logic_vector for everything. This then needs lots of casting and makes the code look bulky and clumsy.

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2016, 10:09:06 am
content: Quote from: nctnico on August 22, 2016, 09:44:57 amI am one of those, I don't use the "unsigned" type(also because I have troubles exporting it from ghdl to C modules)

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2016, 10:31:32 am
content: conclusion:since defining functions is very useful, and it's not so complexprobably we'd better define a pair of direct conversion functionsinput: std_logic_vectoroutput: integerinput: integeroutput: std_logic_vector

author: nctnico
author_rank: Super Contributor
timestamp: August 22, 2016, 11:17:56 am
content: Quote from: legacy on August 22, 2016, 10:31:32 amThose functions are already there! Cast the std_logic_vector to signed or unsigned and then use the function to_integer.http://stackoverflow.com/questions/26683335/vhdl-code-to-convert-5-bit-vector-to-integer

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2016, 11:36:57 am
content: Quote from: nctnico on August 22, 2016, 11:17:56 amlook at your sentence, "and then" means we need two steps, and this is what I want to avoid!I want a directly (1 step) conversion from integer to std_logic_vectortherefore the following needs to be definedu_integer_to_std_logic_vector(integer, size) <---- internally handled as "unsigned"s_integer_to_std_logic_vector(integer, size) <---- internally handled as "signed"positive_to_std_logic_vector(integer, size)std_logic_vector_to_u_integer(std_logic_vector,size) <---- internally handled as "unsigned"std_logic_vector_to_s_integer(std_logic_vector,size) <---- internally handled as "signed"std_logic_vector_to_positive(std_logic_vector,size)

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2016, 11:44:22 am
content: Code:u_integer/positive <= to_integer(unsigned(std_logic_vector));the above will look likeCode:u_integer/positive <= std_logic_vector_to_u_integer(std_logic_vector,size);which makes less confusion and it's absolutely clear(even if the operator's name is too long)

author: nctnico
author_rank: Super Contributor
timestamp: August 22, 2016, 11:57:40 am
content: What happened to 'don't use std_logic_vector'?

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2016, 12:26:59 pm
content: in case, tell me alternatives

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2016, 12:28:52 pm
content: (and don't forget that ghdl has some problems with the unsigned typewhen it needs to be interfaced with C-modules, don't ask me why)

author: legacy
author_rank: Super Contributor
timestamp: August 22, 2016, 01:08:10 pm
content: also the following doesn't work under ghdlCode:library IEEE;use IEEE.STD_LOGIC_1164.ALL;use IEEE.STD_LOGIC_ARITH.ALL;use IEEE.STD_LOGIC_UNSIGNED.ALL;...constant XLEN : integer := 32;subtype cpuWord is std_logic_vector(XLEN -1 downto 0);...when alu_add =>res <= opa + opb + (getStdLogicVectorZeroes(XLEN-1) & cin);Code:use IEEE.STD_LOGIC_ARITH.ALL;use IEEE.STD_LOGIC_UNSIGNED.ALL;those libraries are NOT defined in ghdl and can't be used easilytherefore the "+" operator is not defined for std_logic_vectorand the attempt to simulate "opa + opb" will result an errorinstead you need to useCode:library ieee;use ieee.std_logic_1164.all;use ieee.numeric_std.all;along with the following ugly codeCode:when alu_add =>result <= std_logic_vector(unsigned(opa) + unsigned(opb) +unsigned(getStdLogicVectorZeroes(XLEN-1) & cin));work <= std_logic_vector(unsigned("0" & opa) + unsigned("0" & opb) +unsigned(getStdLogicVectorZeroes(XLEN-1) & cin));in this case "unsigned(opa) + unsigned(opb)" is allowedbecause the "+" operator is defined along with unsignedbut the result needs to be std_logic_vectorboth the above pieces of code come from OpenCorestherefore I assume it's a common troubleedit:Code:entity ALU_arithmetic isPort(enable : in std_logic;-----------------------opa : in cpuWord;opb : in cpuWord;

author: nctnico
author_rank: Super Contributor
timestamp: August 22, 2016, 01:23:33 pm
content: Quote from: legacy on August 22, 2016, 12:26:59 pmThe signed and unsigned types. If a signal represents a number of index (and surprisingly many multi bit signals do) you should not use std_logic_vector. And yes, do use use ieee.numeric_std.all;

author: Pack34
author_rank: Frequent Contributor
timestamp: August 22, 2016, 01:31:21 pm
content: I'm a professional and use both.For maintaining older projects originally written by someone else I use VHDL. However, for newer projects I prefer to use Verilog.I personally prefer Verilog because I just feel more comfortable using it. It's what I was trained on in college and grad school and I feel it's a bit more readable but that's most likely just because I have more experience with it.