Verilog Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Verilog Megathread

priznat: Jul 7, 2009; Let's get drunk and kiss each other all night.

Delta-Wye posted:

I've seen the zedboard and I was tempted to get one, but I don't know what the gently caress I would design with it that I could then turn into something that isn't a zedboard. I may use a microcontroller dev board, break out boards, etc, to prototype an idea but eventually I knock out a PCB and make a standalone solution. All of the Zynq chips are >$100 in small quantities (some over $200!) at digikey, the only supplier I've found that even carries them. Am I missing something obvious? Is there a source for small minimal gumstix-like breakout boards for the processor?

Well you can make an FMC board pretty easily to extend the zedboard capabilities. I did a couple for prototyping a couple different interfaces, DVI and displayport(for the kintex kc705 board) and an LCD touch screen board. They also have a bunch of those PMOD connectors and you can get a grab bag of peripherals from maxim for $90.

Digikey prices suck for the xilinx stuff, but then I guess if you can't go direct to a distributor it's your only option since Avnet will probably tell you to screw off. They're not cheap devices (and super new, it shows in the tools bigtime) but the prices will drop pretty good in the 2014-15 timeframe, I'm guessing.

The Zynqs are ideal for what we're doing now as board controllers with built in glue logic, and down the road we'll be doing rack based automation systems using them in cards. They'll supplant having to use a complete extended PC setup so despite the cost of the devices we'll still save money. True, we could put down an ARM and a discrete FPGA for a little bit less but having the all-in-one solution with transceivers for video in/out is pretty compelling.

# ? Apr 25, 2013 02:22

Adbot: ADBOT LOVES YOU

# ? May 5, 2024 11:07

Delta-Wye: Sep 29, 2005

priznat posted:

The Zynqs are ideal for what we're doing now as board controllers with built in glue logic, and down the road we'll be doing rack based automation systems using them in cards. They'll supplant having to use a complete extended PC setup so despite the cost of the devices we'll still save money. True, we could put down an ARM and a discrete FPGA for a little bit less but having the all-in-one solution with transceivers for video in/out is pretty compelling.

I guess my point is you're not going to design your project around the zedboard, you're going to eventually move your prototyped solution to a custom board around the Zynq itself. I don't think the average hobbyist could do that with the Zynq, between the cost, package, and a whole host of other factors. Which sucks, because it looks badass. Maybe there is some money to be made in a breakout board though. If you can sell a couple thousand you might be able to start getting into lower-end volume pricing and Xilinx does most of the software support for the toolchain.

# ? Apr 25, 2013 02:59

priznat: Jul 7, 2009; Let's get drunk and kiss each other all night.

Yeah the zedboard is kind of a niche thing but it is a great introductory board for the Zynq. Especially since the ZC702 doesn't do much more and is over 3x as much iirc.

Most of the design for the board controller will be done on the zedboard with the FMC LCD panel and the only major change will be the pin constraints for the most parts. A couple minor differences with the embedded interfaces being used but the drivers and kernel will be the same. Implementing it this way lets us get a huge jump since when our board comes back everything should be pretty much ready to go so we can hit the ground running.

The change to devicetree in Linux is great, really decouples the having to recompile kernels based on the board setup, btw.

# ? Apr 25, 2013 03:48

movax: Aug 30, 2008

Anyone try to stuff their Verilog into 80 columns also? Literally made an extra assign statement just to get some stuff to fit in 80 columns; no real negative effect on the synthesis, just seems kinda silly is all.

# ? May 24, 2013 01:24

minidracula: Dec 22, 2007; boo woo boo

movax posted:

Anyone try to stuff their Verilog into 80 columns also? Literally made an extra assign statement just to get some stuff to fit in 80 columns; no real negative effect on the synthesis, just seems kinda silly is all.

I do this (with both Verilog, which I'm relatively new to, and VHDL, where I have [slightly] more background). Try being the operative word.

Unfortunately(?), none of my soon-to-be co-workers do, so it's probably not worth the effort. This is the absolute least of my current "style" concerns with them though, and I'm the Verilog newbie.

I don't know if I've actually gone and made another assign (or similar) like you did, but attempting to keep things in 80 characters is something I still do by default for most languages.

On another topic, is anyone else here doing the NC State University Engineering Online Digital ASIC Design Summer 2013 (whew!) MOOC class?

minidracula fucked around with this message at 20:31 on May 29, 2013

# ? May 29, 2013 20:28

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

mnd posted:

.

On another topic, is anyone else here doing the NC State University Engineering Online Digital ASIC Design Summer 2013 (whew!) MOOC class?

Got a link ? Would be interested in joining you.

Also what do people think about zynq/cyclone v soc et al? Being able to programmable add hardware to a Little Linux board sounds cool.

# ? May 29, 2013 22:39

movax: Aug 30, 2008

Malcolm XML posted:

Got a link ? Would be interested in joining you.

Also what do people think about zynq/cyclone v soc et al? Being able to programmable add hardware to a Little Linux board sounds cool.

I googled it, looks like unless I missed something, registration is closed / class slides & materials aren't shared directly.

Zynq and Cyclone V are both great ideas; Cyclone V is nowhere near ready (I would honestly say it is a good year at the least behind Zynq, and I'm an Altera fan) though. Zynq has a lot of little details you have to get right (by repeatedly reading the docs) but it's shipping now/very soon, and Xilinx is using it as a good excuse to clean up their development tools.

We're using Zynq as the core of our new product, and it's really the only thing enabling us to meet a lot of targets simply because we can do our own hardware (critical for this application, lots of hardware control loops + acquisition) and port our existing Linux software over to the exact same piece of silicon, all with a stupidly low TDP that lets us run at 50C+ without a fan.

Hopefully Zynq sells well and Xilinx will upgrade the PS (ARM) half of the equation fairly frequently; the A9 sadly suffers from memory performance issues (like half the smartphone/tablet market running A9s right now). Xilinx also seems to be ahead of the game when it comes to kernel support; they're stupidly fast when it comes to matching mainline.

Altera had one thing going for them which was cost, but after the inability for them to deliver dev kits + an apparent lack of support in Quartus (even Beta 13), we switched to Xilinx. Get your poo poo together guys :argh:

# ? May 29, 2013 22:50

minidracula: Dec 22, 2007; boo woo boo

Malcolm XML posted:

Got a link ? Would be interested in joining you.

Yeah, sorry about that, it looks like the last day for registration was Saturday, May 25.

The relevant page (FWIW) is: http://go.distance.ncsu.edu/digital-asic/

# ? May 30, 2013 02:23

Malcolm XML: Aug 8, 2009; I always knew it would end like ｔｈｉｓ．

mnd posted:

Yeah, sorry about that, it looks like the last day for registration was Saturday, May 25.

The relevant page (FWIW) is: http://go.distance.ncsu.edu/digital-asic/

Man all I want is to make the beeps and the boops and everything has to get in the way.

Is it just me or is the Quartus UI supposed to be terrible?

# ? May 30, 2013 18:45

movax: Aug 30, 2008

Malcolm XML posted:

Man all I want is to make the beeps and the boops and everything has to get in the way.

Is it just me or is the Quartus UI supposed to be terrible?

All EDA tools are terrible with terrible UIs because who the gently caress else's tools are you going to use?

Still better than ISE IMHO.

# ? May 30, 2013 19:04

priznat: Jul 7, 2009; Let's get drunk and kiss each other all night.

Been using the Vivado IP Integrator (had to request early access license) and it's definitely better than the shitshow that planahead/XPS was for Zynq stuff.

Unfortunately it's still not very stable and will occasionally crash without warning or just refuse to synthesize with no error message given. Hence the early access license!

They've really streamlined the creation of IP blocks though, it will auto detect that you've put an AXI port on and create a block you can just hook up using a schematic like tool. Everything is captured in XML and it generates a (flattened) RTL (I'm in VHDL but I assume if you set the project to verilog it'll do that too) based on the XML.

Course you can turf all that too and just to straight RTL but this way is pretty nice for configuring all the Zynq functions and setting up the memory map etc.

# ? May 30, 2013 19:09

Delta-Wye: Sep 29, 2005

So I have a stupid question about Moore state machines. All of the examples I've seen jump from one state to the next and generate combinatorial outputs. I want to do work in each state. Is it weird to have a statemachine that just sits in an individual state for a certain amount of clocks before moving on? Most of the ones I've seen having something like:

code:

if state = S1 then
    output <= '0';
elsif state = S2 then
    output <= '1';
end if;

and a separate process for dealing with combinatorial inputs and generating the appropriate 'next_state' variable along with another seperate process for doing the state transitions.

What I want to do is something more like:

code:

variable cntr : integer;
if state = S1 then
    output <= '0';
    if cntr < 50 then
        -- do something for 50 clocks
        cntr := cntr + 1;
    else
        next_state <= S2;
    end if;
elsif state = S2 then
    output <= '1';
end if;

HDLs kill me because there is such a huge gulf between "compiles and works" and "is synthesizable". Also, there is "synthesizes well" to consider on top of that.

The other plan is to split up the state machine and the work. If the state machine is in a certain state, a process sees this and does the work and then sets a flag and eventually the state machine control process sees it and it proceeds to the next one. I'm just not seeing the value in organizing things that way other than the fact it matches a lot of the examples I've seen closer.

Delta-Wye fucked around with this message at 22:22 on Jun 14, 2013

# ? Jun 14, 2013 22:14

JawnV6: Jul 4, 2004; So hot ...

Delta-Wye posted:

The other plan is to split up the state machine and the work. If the state machine is in a certain state, a process sees this and does the work and then sets a flag and eventually the state machine control process sees it and it proceeds to the next one. I'm just not seeing the value in organizing things that way other than the fact it matches a lot of the examples I've seen closer.

Think of it like crude OOP. Your state machine logic is living by itself with the inputs for arcs clearly coming in and influencing the next state decision. The work is being done by another circuit that's looking at the current state to decide what to do. Or since it's hardware, just have it working all the time always and only sample when the current state should care about the output. It might make sense to club it all together if it's a small enough block, but anything over a page of code and I'd get nervous about forgetting what section I was in.

Is every state exactly 50 clocks? Or is there some variability you're accounting for between states? From your brief description I'd be tempted to break that check out to another block and pull in the result of the check to the next state logic.

Also... "integer"? Hope that's test code.

# ? Jun 14, 2013 22:27

Delta-Wye: Sep 29, 2005

JawnV6 posted:

Think of it like crude OOP. Your state machine logic is living by itself with the inputs for arcs clearly coming in and influencing the next state decision. The work is being done by another circuit that's looking at the current state to decide what to do. Or since it's hardware, just have it working all the time always and only sample when the current state should care about the output. It might make sense to club it all together if it's a small enough block, but anything over a page of code and I'd get nervous about forgetting what section I was in.

Is every state exactly 50 clocks? Or is there some variability you're accounting for between states? From your brief description I'd be tempted to break that check out to another block and pull in the result of the check to the next state logic.

Also... "integer"? Hope that's test code.

The work is different depending on what state and the inputs for processing. I'm wrapping my head around this a bit better.

It IS test code (just dicking around at the moment) but I don't want to get in bad habits right off the bat. I see the following casts all the time:

code:

signal cntr: std_logic_vector(7 downto 0);
...
cntr <= std_logic_vector(unsigned(cntr) + 1);

Looks messy as gently caress. Is that actually preferable?

EDIT: ha. cntr : unsigned(7 downto 0); looks like a winner except it won't let me use it to index other bit arrays. Natural (well, 'positive') works but I'm not sure about synth. :iiam:

HDLing ain't easy.

Delta-Wye fucked around with this message at 23:11 on Jun 14, 2013

# ? Jun 14, 2013 22:41

JawnV6: Jul 4, 2004; So hot ...

There's no such thing as an integer. There's bits that we can gang together and pretend are an integer and treating everything like that will prevent goofy cases where you're testing against 129 with a 7 bit signal and wonder why you're doing fine in simulation with integers but crashing on hardware.

That's VHDL code, not verilog. I can't really speak to it, but agnostic to that I'd prefer one messy line that took me half a minute to remember what it did twice a project when I had to look at it.

This is even how I've seen embedded and game code (the only other places I've seen state machines) represent FSM's, with the glue holding things together condensed down to a page with functions that call out to the work that has to be done in each state.

Something like this:

code:

case(state)
  S1: if(arcS1toS2) next_state = S2;
  S2: if(arcS2toS1) next_state = S2;
endcase

always (@posedge clk) 
  state <= next_state;

I haven't written verilog in a few months now, so I've doubtless confused some = <=, but the point is that a case() should be used to choose between states instead of if/else and state should sample next_state on some clock edge to advance.

# ? Jun 14, 2013 23:12

Delta-Wye: Sep 29, 2005

JawnV6 posted:

There's no such thing as an integer. There's bits that we can gang together and pretend are an integer and treating everything like that will prevent goofy cases where you're testing against 129 with a 7 bit signal and wonder why you're doing fine in simulation with integers but crashing on hardware.

That's VHDL code, not verilog. I can't really speak to it, but agnostic to that I'd prefer one messy line that took me half a minute to remember what it did twice a project when I had to look at it.

This is even how I've seen embedded and game code (the only other places I've seen state machines) represent FSM's, with the glue holding things together condensed down to a page with functions that call out to the work that has to be done in each state.

Something like this:
code:
case(state)
  S1: if(arcS1toS2) next_state = S2;
  S2: if(arcS2toS1) next_state = S2;
endcase

always (@posedge clk) 
  state <= next_state;
I haven't written verilog in a few months now, so I've doubtless confused some = <=, but the point is that a case() should be used to choose between states instead of if/else and state should sample next_state on some clock edge to advance.

I'm on top of all that except for the datatypes. Here is a page recommending using the 'integer' type and letting the synthesizer figure it all out:

http://www.jandecaluwe.com/hdldesign/counting.html

# ? Jun 14, 2013 23:22

JawnV6: Jul 4, 2004; So hot ...

Eh, guess I'm the 'Verilog die hard' being dismissed early in the text. It would be nice if the tools took care of it, I've just had enough issues when I gave up that level of control that I'm wary to recommend it.

What kind of 'work' are you doing in each state? The code I gave was just the 'control' portion of the FSM, the point being that each state is only a set of conditions to shove something into 'next_state'. Most kinds of 'work' that I'm imagining can be active no matter what state it's in, with the control signals selecting out of that what's relevant.

# ? Jun 14, 2013 23:34

Delta-Wye: Sep 29, 2005

JawnV6 posted:

Eh, guess I'm the 'Verilog die hard' being dismissed early in the text. It would be nice if the tools took care of it, I've just had enough issues when I gave up that level of control that I'm wary to recommend it.

What kind of 'work' are you doing in each state? The code I gave was just the 'control' portion of the FSM, the point being that each state is only a set of conditions to shove something into 'next_state'. Most kinds of 'work' that I'm imagining can be active no matter what state it's in, with the control signals selecting out of that what's relevant.

Data processing - enumerated states, just roughly:
initialization
idle (waiting to be notified it has a full data set, the transmission is handled by another setup and i should just be able to read it from a register)
offload the data into an IP core (this takes multiple cycles for the whole set)
Waiting for processing - just sit here until the core sets a flag that it's done.

The initialization state is the only one in which I'm really tracking loops at the moment, I guess. I'm filling some registers with random data, and I need to know when the register is full. My LFSR produces one bit per clock so I need to count out the number of bits I've set and finish when it's done. At least, that's how I'm envisioning it. I'm just starting to dig back into HDL and it's taking a bit of effort to get back into the designing hardware instead of writing software mindset.

EDIT:

quote:

Eh, guess I'm the 'Verilog die hard' being dismissed early in the text. It would be nice if the tools took care of it, I've just had enough issues when I gave up that level of control that I'm wary to recommend it.

FWIW, I'm of this mindset as well - if you aren't explicitly doing it, how do you know it's being done correctly? The only issue here is there is a HUGE complicated process (synthesis) that I cannot control and it makes me weary.

Delta-Wye fucked around with this message at 00:18 on Jun 15, 2013

# ? Jun 14, 2013 23:48

NevilleBamshoe: Feb 19, 2013

Why not rather call the thread HDL Megathread? VHDL is quite a bit more prevalent outside the US.

# ? Jul 4, 2013 09:34

priznat: Jul 7, 2009; Let's get drunk and kiss each other all night.

VHDL is the metric to Verilog's imperial :haw:

(I prefer VHDL but use both)

# ? Jul 4, 2013 21:56

NevilleBamshoe: Feb 19, 2013

Question for the FPGA guys. How many of you make use of dynamic timing analysis in your designs (post fitting timing simulations)? Or do you mostly get away with only static analysis? I'm referring specifically to designs with multiple time domains.

# ? Jul 5, 2013 10:21

Schmerm: Sep 1, 2000; College Slice

NevilleBamshoe posted:

Question for the FPGA guys. How many of you make use of dynamic timing analysis in your designs (post fitting timing simulations)? Or do you mostly get away with only static analysis? I'm referring specifically to designs with multiple time domains.

Speaking as an Altera user, I trust the synchronization primitives (the dcfifo and the altera standard synchronizer whose name I forget) for moving data between clock domains safely. Then, only static timing analysis post-fitting is needed. The STA tool also does metastability analysis and it usually gives MTBFs in the billions of years.

# ? Jul 8, 2013 17:34

Delta-Wye: Sep 29, 2005

Best practices for synthesis question:

I have a statemachine that walks through states doing it's thing. This is great, but one of the states needs to do the same thing for 8 clocks. The Xilinx example Moore statemachine relies on three processes for running, a single process that assigns state <= next_state, a process that changes outputs based on the current value of state, and another process that determines the next_state from the current state plus inputs. This is great, but I'm not sure the easiest and cleanest way to get it to stay in a single state for a number of clocks (effectively for a certain amount of time). I have a few ways to do this in simulation, but I'm not sure which solution is more common and easier for the synthesis tool to make sense of.

1: Create a hardware counter. I did this with a shift register - when you enter the state, it starts shifting '1', and when the '1' pops out the other side, transitions. The implementation is in a separate vhdl file and is literally a std_logic_vector whose length is set as a generic parameter. This works, but seems like it ties the synthesis tools hands a bit by being specific.

2: Use a variable to control timing. The process for determining next state has a synchronous section that increments the variable and once it hits a certain amount, moves to the next state. I am hesitant to use variables because I do not have a good feeling for what hardware they turn into, but this is a pretty clean way to do it code-wise.

3: Add additional states. This seems kind of grotesque but I could simply have a bunch of states do_work_0 through do_work_7 instead of trying to sit in state do_work for 8 clocks. No counting necessary, it just walks through the states. However, I have a state machine with 12 states already, and this would balloon it up to 40 or so.

4: Additional state machine. I could build another state machine that just walks through eight states and use its outputs to control the main state machine. Seems similar to #2 in every way but implementation, to be honest. And if you have one-hot encoding, I suspect it will look very similar post synthesis.

I'm getting comfortable with VHDL, but I still have a huge black hole in my library of "design patterns" and I am still uncomfortable with the synthesis tool; I write code that will pass simulation no problem but I don't have a intuitive sense of what happens when I pass it down the toolchain.

I am one big case of analysis paralysis :downs:

# ? Jul 11, 2013 18:01

Schmerm: Sep 1, 2000; College Slice

Delta-Wye posted:

Best practices for synthesis question:

I have a statemachine that walks through states doing it's thing. This is great, but one of the states needs to do the same thing for 8 clocks. The Xilinx example Moore statemachine relies on three processes for running, a single process that assigns state <= next_state, a process that changes outputs based on the current value of state, and another process that determines the next_state from the current state plus inputs. This is great, but I'm not sure the easiest and cleanest way to get it to stay in a single state for a number of clocks (effectively for a certain amount of time). I have a few ways to do this in simulation, but I'm not sure which solution is more common and easier for the synthesis tool to make sense of.

1: Create a hardware counter. I did this with a shift register - when you enter the state, it starts shifting '1', and when the '1' pops out the other side, transitions. The implementation is in a separate vhdl file and is literally a std_logic_vector whose length is set as a generic parameter. This works, but seems like it ties the synthesis tools hands a bit by being specific.

2: Use a variable to control timing. The process for determining next state has a synchronous section that increments the variable and once it hits a certain amount, moves to the next state. I am hesitant to use variables because I do not have a good feeling for what hardware they turn into, but this is a pretty clean way to do it code-wise.

3: Add additional states. This seems kind of grotesque but I could simply have a bunch of states do_work_0 through do_work_7 instead of trying to sit in state do_work for 8 clocks. No counting necessary, it just walks through the states. However, I have a state machine with 12 states already, and this would balloon it up to 40 or so.

4: Additional state machine. I could build another state machine that just walks through eight states and use its outputs to control the main state machine. Seems similar to #2 in every way but implementation, to be honest. And if you have one-hot encoding, I suspect it will look very similar post synthesis.

I'm getting comfortable with VHDL, but I still have a huge black hole in my library of "design patterns" and I am still uncomfortable with the synthesis tool; I write code that will pass simulation no problem but I don't have a intuitive sense of what happens when I pass it down the toolchain.

I am one big case of analysis paralysis

Ew, VHDL. Aside from that, option 1 is essentially what I use whenever this needs to be done. Don't do #2 because it might break the synthesis tool's recognition of the state machine, since the logic will no longer be an unconditional "every clock, copy nextstate to state". 3 and 4 are identical but messy. #1, if done using a one-hot counter (= shift register) will be just as efficient as whatever state machines get synthesized as these days.

# ? Jul 11, 2013 19:19

JawnV6: Jul 4, 2004; So hot ...

Schmerm posted:

Ew, VHDL. Aside from that, option 1 is essentially what I use whenever this needs to be done. Don't do #2 because it might break the synthesis tool's recognition of the state machine, since the logic will no longer be an unconditional "every clock, copy nextstate to state". 3 and 4 are identical but messy. #1, if done using a one-hot counter (= shift register) will be just as efficient as whatever state machines get synthesized as these days.

I was reading #2 as the do_work state incrementing a 3-bit counter, checking for '111, and setting next_state to after_work on a match. Not actually controlling the state <= next_state assignment based on the counter value?

Either a shift register or a counter is a trivial amount of gates. Shift register might come out ahead, but I would've slapped a counter in it and moved on.

# ? Jul 11, 2013 19:24

Delta-Wye: Sep 29, 2005

JawnV6 posted:

I was reading #2 as the do_work state incrementing a 3-bit counter, checking for '111, and setting next_state to after_work on a match. Not actually controlling the state <= next_state assignment based on the counter value?

Either a shift register or a counter is a trivial amount of gates. Shift register might come out ahead, but I would've slapped a counter in it and moved on.

Your reading was correct, it wasn't totally clear in my explanation. The state <= next_state assignment is happening in a dedicated process like the language template recommends, all of the counter ops are happening in the "next_state_decode" process, which assigns a value to next_state initially.

I'm building a couple simple state machines at the moment to synthesis the different approaches. Unfortunately, the synthesizer is smart enough that the simple toy state machines my have different performance characteristics, but it at least gives me some quantitative information to go on.

# ? Jul 11, 2013 19:34

movax: Aug 30, 2008

Just going to post to bump again that if you want to move to beautiful Ann Arbor, MI and have FPGA experience (primarily) plus some hardware and Linux experience, there's a nice paycheck waiting.

# ? Jul 22, 2013 22:19

minidracula: Dec 22, 2007; boo woo boo

movax posted:

Just going to post to bump again that if you want to move to beautiful Ann Arbor, MI and have FPGA experience (primarily) plus some hardware and Linux experience, there's a nice paycheck waiting.

I remember you saying this was you trying to find someone to take over your old job, but aren't you in the PNW now?

Also, I take it you already are jobb? If not, do let me know.

# ? Jul 23, 2013 09:45

movax: Aug 30, 2008

mnd posted:

I remember you saying this was you trying to find someone to take over your old job, but aren't you in the PNW now?

Also, I take it you already are jobb? If not, do let me know.

I'll be there in a bit, it's my last week right now, just trying to find them someone as I realize more and more how much they need someone fast.

I am job'd up in the PNW though, certainly wouldn't move like 2500 miles without that lined up!

# ? Jul 23, 2013 21:27

Delta-Wye: Sep 29, 2005

Doe anyone know of a good reference for writing nice synthesizable VHDL for FPGAs? I would survive with a Verilog reference as well, as I'm less interested in . The more I play with HDL the more I realize I don't have a very intuitive grasp of some of the finer points of what my code may be synthesizing into and why. Something that explaines the hdlbeard's rules of thumb, has code examples, etc, would be ideal.

# ? Aug 4, 2013 23:59

priznat: Jul 7, 2009; Let's get drunk and kiss each other all night.

I've had Qualis' Quick Reference card around for VHDL for ages now, usually when I get back into coding VHDL after not doing it for a while I refer to it constantly.

http://www.eda.org/rassp/vhdl/guidelines/vhdlqrc.pdf

Doesn't have examples per se more just a syntax helper. Also it doesn't have some of the newer handy things like the one from VHDL 2002(? not sure what date) where you can instantiate blocks without having to have a component declaration. That's a real timesaver.

Probably not really what you meant by synthesizable VHDL though. That'd be a lot more tricky to condense into a quick reference!

What's HDLBeard's rules of thumb? Curious about that, never heard about it.

priznat fucked around with this message at 00:28 on Aug 5, 2013

# ? Aug 5, 2013 00:24

Delta-Wye: Sep 29, 2005

I did a poor job explaining myself. I'm less interested in language details, and more interested in patterns and practices when developing for FPGAs. For instance, I was recently told that clock gating is often a terrible idea because it may prevent the synthesizer from utilizing the built-in clock distribution networks. I can't vouch for the veracity of that statement, but stuff like that isn't inherently obvious from just knowing the language and I was hoping to find a reference source that would allow me to short-cut most of the massive amounts of failing learning this stuff usually takes.

HDLBeard was a joke (maybe the term 'unixbeard' isn't that common?). I'm just saying people who have done this sort of stuff a while have a pretty good idea of what works and what doesn't intuitively and I want to become one of these people asap :smith:

# ? Aug 5, 2013 01:08

priznat: Jul 7, 2009; Let's get drunk and kiss each other all night.

Ahh, I see.. Probably a good way to get in to best practices would be looking at the vendors app notes especially. I know Xilinx has a mountain of decent information. Synopsys would be another good one for the Synplify tool but I think you may have to register with a company account to get access to their documentation.

Definitely try to avoid clock gating, some of the better tools (like synplify pro/premier) will convert gated clocks for you automagically. However it doesn't always work and can be a pain to track down. I've got a support call in with Synopsys on that very thing right now.

On another note, I just saw the MicroZed board that Avnet is selling for $199, a smaller zynq device than what is on the zedboard with some expansion ports for plugging into a carrier card (none available yet).

http://zedboard.org/product/microzed

I'm pretty chuffed because I just got the zynq build flow all sorted out using our makefile setup. Have to build the zynq stuff in vivado separately and then export as an .edn file otherwise you won't be able to get the board support package setup easily in the SDK, but not a huge hassle. Secretly I enjoy using the IP Integrator block diagram thing, it's kind of fun. Then just pull some of the ports out to attach my own logic to the AXI ports, because their IP block packager stuff is a huuuuuge pain in the rear end and not worth the trouble.

priznat fucked around with this message at 01:45 on Aug 5, 2013

# ? Aug 5, 2013 01:43

movax: Aug 30, 2008

Phone-posting, sorry, but IMO getting your job to pay for the better training courses, sponging off senior engineers, reading app notes and experimenting on your own are probably the only/best ways to improve your knowledge. Logic design is just one of those fields, I guess.

# ? Aug 5, 2013 04:17

priznat: Jul 7, 2009; Let's get drunk and kiss each other all night.

It really is. One thing I like to do is build up my own mini library of implementations that work well and tweak the hell out of them so I can get really deterministic results both in area and performance.

Very rarely do I find a "clever" or complex way to do something will produce the best results from the tool. Treat them as if they are simpletons and you won't be disappointed.

It also helps a lot when coming back to code I haven't looked at in a while but that is true of any language, really.

Also: always try to make things as generic as possible, within reason.

priznat fucked around with this message at 08:02 on Aug 5, 2013

# ? Aug 5, 2013 07:59

Delta-Wye: Sep 29, 2005

movax posted:

Phone-posting, sorry, but IMO getting your job to pay for the better training courses, sponging off senior engineers, reading app notes and experimenting on your own are probably the only/best ways to improve your knowledge. Logic design is just one of those fields, I guess.

Senior engineers? We don't have a lot of those to be honest but I'm doing what I can.

# ? Aug 6, 2013 05:16

duck monster: Dec 15, 2004

Delta-Wye posted:

Keep in mind I completely toasted a monitor's DVI port (luckily the the VGA port worked and I just rotated it back into the lab's collection, heh)

This is pretty much a tl;dr description of my previous life as a video gear electronics dude at a large corporation.

"Oh hey, smoked the $15K 3 gun projector" *quietly slides the unit back into its case and doctors the checkout logs*

Fortunately that company was so filthy loving rich it didn't matter. It probably didn't get taken out the case again until a decade later when it was being written off for depreciation along with about 90 others.

# ? Aug 6, 2013 10:17

karasu: Jan 3, 2008

I'm looking for some career advice, if this is better suited in the general engineer thread let me know.

I'm a fourth semester EE student and just started a summer internship writing FPGA modules in VHDL for embedded video systems. I saw my first line of VHDL code five weeks ago and have never had any digital design classes before so I was pretty anxious starting out. But I'm apparently doing fairly well because my supervisor keeps asking me to do my bachelors project with them hinting that they would pay for the rest of my bachelors degree and my masters if I keep working for them during semester breaks.

The thing is I'm really not sure if this is the right choice. It's a mid-size company with only twenty something hard/software engineers working on a dozen projects. The FPGA team is severely understaffed and the people who created the most complicated and important modules left the company or retired. And the few people that write any VHDL won't have the time to teach me all that much. There are very few digital design courses at my small college and no VHDL at all so I would learn this stuff on my own. This worked well so far, in the short time I've been there I rewrote one module which had drastic improvements in logic cell usage, which is probably why they offered me a job. I had a lot of fun doing it too, although I doubt I can replicate these kinds of successes in the near future. I'm a bit worried that working in such a small company and team will make me unattractive to possible future, bigger employers. I'm also uncertain about specializing on Altera FPGAs of all things, I have no idea what the job marked looks like for that kind of skill set here in Europe. I do have the option to work in the US but that's Verilog land, right?

On the other hand, paying for my degree is a big loving deal to me since this means I can get rid of my terrible computer janitor job that barely pays for my living expenses. I'm also in my mid 20s with no relevant industry experience (this is my first internship) and don't have the greatest of resumes so this could be one of the few chances to get a foot in the door. I don't know how far my good GPA(3.7) and assistant prof/tutor jobs at my college compensate for that though.

So, any advice for a potential future FPGA engineer? We're working on Cyclone IVs coupled with a Cortex M3. I'd mostly be writing and rewriting video algorithms and adjust their interface to the micro controller.

# ? Aug 14, 2013 20:11

JawnV6: Jul 4, 2004; So hot ...

karasu posted:

I'm looking for some career advice, if this is better suited in the general engineer thread let me know.

You'd probably get more attention in the more generic threads. This thread has like... 5 regulars? If that? The Newbie Interview thread could probably help as well.

karasu posted:

I'm a bit worried that working in such a small company and team will make me unattractive to possible future, bigger employers. I'm also uncertain about specializing on Altera FPGAs of all things, I have no idea what the job marked looks like for that kind of skill set here in Europe. I do have the option to work in the US but that's Verilog land, right?

I wouldn't be concerned about either of these things. We're talking about how you'll spend your summer breaks from class, right? I had one summer out of four with germane research, the rest didn't go on my resume and nobody asked. The fact that some company, any company, wants you back after spending a few months is a good sign. I wouldn't worry about specialization, digital design skills are pretty fungible across FPGA's and even languages to a degree. My first professional project used an in-house HDL.

karasu posted:

We're working on Cyclone IVs coupled with a Cortex M3. I'd mostly be writing and rewriting video algorithms and adjust their interface to the micro controller.

This is solid gold experience. Really can't see any glaring problems with it. I'd advise that you try to take some digital design coursework and computer architecture if you can.

# ? Aug 15, 2013 01:00

Adbot: ADBOT LOVES YOU

# ? May 5, 2024 11:07

movax: Aug 30, 2008

Yeah, you're in solid shape I would say. Especially if you have a command of the English language and aren't one of the 1000s of Indian FPGA engineers who post desperately on forums cobbling together random example code into a product. Sounds like you're getting paid to learn and play with FPGAs, and you're doing pretty solid with it.

I certainly wouldn't worry about Altera vs. Xilinx either; they're the two major FPGA vendor in terms of performance devices (Stratix and Virtex) though I think Xilinx still dominates in volume.

# ? Aug 15, 2013 16:52

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Verilog Megathread

«‹›7 »