Verilog Megathread

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

Popete: Oct 6, 2009; This will make sure you don't suggest to the KDz
That he should grow greens instead of crushing on MCs; Grimey Drawer

Forward
I am a Computer Engineering undergraduate stepping into the wide world of HDL's this is also my first megathread. I will be the first to admit that a lot of this is new to me, so sorry for the lack of in depth information as this thread grows hopefully we can expand this section to be more accessible to newcomers like myself.

What is Verilog?
Verilog is an HDL (hardware description language). It describes electronic circuitry in a "coding" environment. Gone are the days of designing hardware circuitry using hand drawn schematics or schematic software. HDL's over shematic design is like programming in an HLL compared to assembly code. Verilog is one of the largest languages in the world, others include VHDL (not to be confused with Verilog), System Verilog, and others I'm not familiar with. Back when integrated circuits where made up of only a few thousand transistors designing them by hand was feasible albeit timely. Now in the ages of multi-million to over a billion count transistor circuits HDL's are the only way to design. The tools allow us to using libraries of fabricated parts, synthesize designs into a manufacturable chip based on our design parameters (time, area, speed).

Resources

IEEE Verilog 2001 standard this is a highly accessible standard from IEEE. I recommend this as a main reference when designing it is very easy to read and covers just about everything.

Nonblocking Assignments in Verilog Synthesis, Coding Styles that Kill! This is an amazing guideline written very clearly and demystifies blocking and nonblocking statements when and how to use them in your designs. A must read for anyone learning Verilog.

Sunburst-design This website contains lots of articles such as the one posted above.

Environments
Admittedly this is something I do not know much about myself, I have only ever designed in Verilog and thus have used Modelsim which seems to be the premier environment. It allows you to compile your designs then functionally simulate them in a fairly easy to use program. There is a free student version on the Modelsim website with reduced performance, and you are not allow to sell your designs of course.

More to come
Help me make this a better thread, all you HDL designers out there post your favorite papers and resources on Verilog. What are some good beginner tips? Anything you want in the op just let me know in here and I'll put it in the OP.

# ? Sep 28, 2011 00:17

Adbot: ADBOT LOVES YOU

# ? May 5, 2024 15:29

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

Checkin' in to the megathread! I've been a Verilog programmer/hardware engineer for about 4 years now, and can (try to) answer any questions anybody might have about Verilog, coding styles, FPGAs/CPLDs generally, or the Xilinx family of FPGAs and tools.

The best resource I've found on the net for learning Verilog was this one: http://www.asic-world.com/verilog/. It's pretty web-one-point-oh, but the information there is well presented and very accurate.

Poopernickel fucked around with this message at 22:26 on Oct 6, 2011

# ? Oct 6, 2011 22:22

blorpy: Jan 5, 2005

the best way to learn verilog is to sit down and thumb through the milkymist source

# ? Oct 9, 2011 05:01

lostchicken: Sep 6, 2004; "Well, I suppose he's... mostly harmless..."

Also, try SystemVerilog, Verilog-2001's less retarded cousin!

Basically, all you need to know is that you can route around busses instead of zillions of wires, and you can use "logic" instead of "wire" or "reg", thereby ensuring that you don't always pick the wrong one. It's a generally cleaner environment. I've done big projects in it even knowing that I'd have to port back to Verilog-2001. Debugging is just a whole boatload easier.

The spec used to be public, but you can find it on IEEExplore if you dig around.

# ? Oct 11, 2011 05:56

horse_ebookmarklet: Oct 6, 2003; can I play too?

So I have a question!
I've build a 'Conway's Game of Life' module in Verilog, and I need some advice on a problem.
I have two arrays of registers, representing a current and the new state. Once I've calculated the new state, I need to essentially 'rename' the new register to the 'current' one. I need to do this in order to iterate again.

What sort of approach should I take to this?

I'm new to Verilog, and I've had some experience with VHDL in the past.

e: I'm away from my desktop, but it just occurred to me, is it possible to mux an array?

horse_ebookmarklet fucked around with this message at 07:48 on Oct 14, 2011

# ? Oct 14, 2011 07:44

Sinestro: Oct 31, 2010; The perfect day needs the perfect set of wheels.

NotHet posted:

So I have a question!
I've build a 'Conway's Game of Life' module in Verilog, and I need some advice on a problem.
I have two arrays of registers, representing a current and the new state. Once I've calculated the new state, I need to essentially 'rename' the new register to the 'current' one. I need to do this in order to iterate again.

What sort of approach should I take to this?

I'm new to Verilog, and I've had some experience with VHDL in the past.

e: I'm away from my desktop, but it just occurred to me, is it possible to mux an array?

Just do essentially:

code:

x = x xor y
y = x xor y
x = x xor y

for each register

# ? Oct 14, 2011 08:41

horse_ebookmarklet: Oct 6, 2003; can I play too?

Sinestro posted:

Just do essentially:
code:
x = x xor y
y = x xor y
x = x xor y
for each register

Hmm I have a followup question then. My array currently has 8 registers (with a width of 8), so I'd have to do 8 assignments. If I were using a much larger array, for instance 128 by 32, would this be a good approach? How badly would something like this negatively impact timing?
I suppose I could break this up across multiple cycles, but this seems clumsier than what I'm currently doing.

My current strategy is to contain all my reads and writes in if blocks directing it to the appropriate array.

# ? Oct 14, 2011 16:00

Justus: Apr 18, 2006; ...

I apologize in advance if there might be a better place to post this.

I think I could use some advice. I'm a recent graduate with a Bachelor's in EET, and I just landed my first industry job doing FPGA design for a tiny start-up that makes iOS software with peripherals. Today is in fact my second day on the job. They've given me a protoboard to play with (Lattice Machxo2 Control) and I'm supposed to become their resident Verilog expert. I suppose this is probably very common for anyone's first job, but I'm feeling kind of lost and a bit overwhelmed. I took several classes on embedded programming in school, and one in particular that focused on HDLs (we used VHDL), and I even programmed a neat little traffic controller in that class. But I feel like now, on the job, there are a lot of things I come across that I don't really understand, and I don't want to constantly be bothering my two very busy co-workers about all of it.

I've just ordered Bhasker's "A Verilog HDL Primer" off of Amazon, and it looks like a good gentle introduction to Verilog, but I feel as if I might need something even more basic covering modern digital design...or something so that I can understand at least half of the lingo that gets thrown about.

tldr - Does anyone have any good books to recommend? Or advice? Maybe I just need to chill?

# ? Oct 15, 2011 00:58

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

NotHet posted:

Hmm I have a followup question then. My array currently has 8 registers (with a width of 8), so I'd have to do 8 assignments. If I were using a much larger array, for instance 128 by 32, would this be a good approach? How badly would something like this negatively impact timing?

It doesn't matter how many registers you have, in a good implementation they'll all be swapped simultaneously. Especially if nothing actually moves and you just get a rename.

That said, I'm not sure I'd use the xor setup - using a temporary instead makes it clearer that you're just swapping the register sets and has less opportunity for a dumb synthesizer to do something dumb.

quote:

My current strategy is to contain all my reads and writes in if blocks directing it to the appropriate array.

This is actually the optimal hardware solution, by the way - anything else is basically a question of whether the synthesizer can finagle it into something equivalent to this.

# ? Oct 15, 2011 03:07

Colonel Taint: Mar 14, 2004

Justus posted:

tldr - Does anyone have any good books to recommend? Or advice? Maybe I just need to chill?

Altera has some good free (requires registration) lessons about verilog and PLDs in general. See http://www.altera.com/education/training/curriculum/fpga/trn-fpga.html There is some vendor specific stuff, but they also cover the basics in a pretty straightforward fashion. Personally I come from a CS/SE background and these lessons were more useful than any book I came across.

The PLD industry is far from standardized, so after you acquaint yourself with the basics, you should dig around Lattice's site to see what kind of info you can find about your specific device. Read through relevant datasheets, manuals, and sample source codes thoroughly.

Some of the small sample projects at http://www.fpga4fun.com/ also helped me get a grasp on things. Again though, some of the content is specific to Altera/Xilinx devices and workflows.

# ? Oct 16, 2011 22:24

Justus: Apr 18, 2006; ...

SintaxError posted:

Altera has some good free (requires registration) lessons about verilog and PLDs in general. See http://www.altera.com/education/training/curriculum/fpga/trn-fpga.html

Hey, that looks like a pretty good resource. Thanks! I'll probably have some specific questions to ask as I get into it.

# ? Oct 17, 2011 01:12

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

NotHet posted:

So I have a question!
I've build a 'Conway's Game of Life' module in Verilog, and I need some advice on a problem.
I have two arrays of registers, representing a current and the new state. Once I've calculated the new state, I need to essentially 'rename' the new register to the 'current' one. I need to do this in order to iterate again.

What sort of approach should I take to this?

I'm new to Verilog, and I've had some experience with VHDL in the past.

e: I'm away from my desktop, but it just occurred to me, is it possible to mux an array?

I did this same assignment in college. Just have a single bit keeping track of which array is the live one. This trick is used all the time (mostly for things like framebuffers). Throw a couple muxes around it that use that bit as the select to direct the reads and writes between them

The XOR trick is the product of a mind broken by software. For the love of all that is digital, do NOT implement that in hardware.

# ? Oct 17, 2011 20:26

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

I'd recommend using a generate block to do the load from your "next" page into your "current" page. Here's an example that creates two 8x16 memory arrays, loads them with an initial value, and switches an output mux between the two pages:

(synthesized fine with Xilinx ISE, didn't try others)

code:

module test(Clk, Mux, Out);

// Module Port I/O Declarations

    input Clk;
    input [3:0] Mux;    

    output [7:0] Out;
   
// Local Variable Declarations

    reg [7:0] bank_1[15:0];
    reg [7:0] bank_2[15:0];

    integer k;
    genvar x;

// Begin Program

    initial begin
        for(k = 0; k < 16; k = k + 1) begin
            bank_1[k] = k;
            bank_2[k] = k + 128;
        end
    end
    
    generate
        for(x = 0; x < 16; x = x + 1) begin: swap_pages
            always @(posedge Clk) begin
                bank_1[x] <= bank_2[x];
                bank_2[x] <= bank_1[x];
            end
        end
    endgenerate
    
    assign Out = bank_1[Mux];
    
endmodule

Edit:
JawnV6's suggestion is a good one too. I think his scheme uses a bigger number of LUTs but mine uses a bigger number of registers.

Poopernickel fucked around with this message at 23:38 on Oct 17, 2011

# ? Oct 17, 2011 23:05

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

Justus posted:

Hey, that looks like a pretty good resource. Thanks! I'll probably have some specific questions to ask as I get into it.

Bhasker's "A Verilog HDL Primer" is a great book, and a very useful resource. I refer to it constantly. The page numbering is "off" between the index/ToC/actual book text by a few pages in my printing, but the book is awesome otherwise. You might also check out that ASIC World link I posted if you want some tutorials/examples. There's nothing ASIC-specific, despite the name :v:

# ? Oct 17, 2011 23:12

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

lostchicken posted:

Also, try SystemVerilog, Verilog-2001's less retarded cousin!

Basically, all you need to know is that you can route around busses instead of zillions of wires, and you can use "logic" instead of "wire" or "reg", thereby ensuring that you don't always pick the wrong one. It's a generally cleaner environment. I've done big projects in it even knowing that I'd have to port back to Verilog-2001. Debugging is just a whole boatload easier.

The spec used to be public, but you can find it on IEEExplore if you dig around.

Which toolchains support SystemVerilog? Would I have to pony up for Mentor/Synopsys stuff if I wanted to go that route in my next design?

# ? Oct 17, 2011 23:13

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

Poopernickel posted:

I'd recommend using a generate block to do the load your "next" page into your "current" page.

Why? Why why why why why?

loving hell, I don't understand why you're all committed to actually shuffling data bits around for this. There's no good reason to worry about carting bits around and having a "current" and "next" hardcoded in the design. Just have two identical data structures and mux the writes and reads between them. poo poo, NotHet even alluded to this solution and you still hopped on the lets-copy-bits train.

Let's say someone comes along and wants a third buffer. Next-next state or whatever. Any solution where you actually carry bits around is going to be hell to extend. But if you're just cycling between two and need to add a third, you're just tossing in a few extra select bits on the muxes, maybe duplicating the read/write logic if it's not possible to time-slice it to do one then the other.

Also since it's on my mind, don't do that XOR poo poo in SW either. You'll pass it two copies of the same pointer, it'll zero them both out, and you'll get to debug a giant system that's dying because you tried to skimp on registers while copying.

# ? Oct 17, 2011 23:41

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

JawnV6 posted:

Why? Why why why why why?

loving hell, I don't understand why you're all committed to actually shuffling data bits around for this. There's no good reason to worry about carting bits around and having a "current" and "next" hardcoded in the design. Just have two identical data structures and mux the writes and reads between them. poo poo, NotHet even alluded to this solution and you still hopped on the lets-copy-bits train.

Let's say someone comes along and wants a third buffer. Next-next state or whatever. Any solution where you actually carry bits around is going to be hell to extend. But if you're just cycling between two and need to add a third, you're just tossing in a few extra select bits on the muxes, maybe duplicating the read/write logic if it's not possible to time-slice it to do one then the other.

Also since it's on my mind, don't do that XOR poo poo in SW either. You'll pass it two copies of the same pointer, it'll zero them both out, and you'll get to debug a giant system that's dying because you tried to skimp on registers while copying.

Agreed that a page-swapping design doesn't scale well when you have more than two pages - in that case, your approach is the one to use for sure. With exactly two pages, however, the logic requirements are lower because the synthesizer doesn't need to implement a mux on each input and output bit.

edit: also, there's the nice advantage that your outputs are registered as opposed to muxed, which gets a better timing score if the output page has to get processed by some other logic.

Poopernickel fucked around with this message at 23:59 on Oct 17, 2011

# ? Oct 17, 2011 23:54

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

I've never been at a place that cared about those metrics at that granularity. Either it's a dont-care or you're doing a better job measuring it than the Xilinx compiler.

# ? Oct 18, 2011 00:25

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

JawnV6 posted:

I've never been at a place that cared about those metrics at that granularity. Either it's a dont-care or you're doing a better job measuring it than the Xilinx compiler.

# ? Oct 18, 2011 00:39

SnoPuppy: Jun 15, 2005

Poopernickel posted:

Agreed that a page-swapping design doesn't scale well when you have more than two pages - in that case, your approach is the one to use for sure. With exactly two pages, however, the logic requirements are lower because the synthesizer doesn't need to implement a mux on each input and output bit.

edit: also, there's the nice advantage that your outputs are registered as opposed to muxed, which gets a better timing score if the output page has to get processed by some other logic.

You probably get the muxes and logic for free if you're implementing it any modern, reasonable FPGA.
If you're using registers, you're consuming a slice and its LUTs regardless if you use them or not, due to the control sets and routing resources.

This whole discussion is exactly why whenever someone at work does something silly, I always, always, always ask them to draw out the schematic of what they're doing. If you can't figure out how to do roughly what you want with gates and FFs, you shouldn't be doing it.
Even if you do know how to implement it with logic and gates, you should still try to have an understanding of your specific part to make sure that the synthesizer wont do something dumb.

Remember that VHDL and Verilog are Hardware Description Languages - not magic, and you certainly don't write "programs" with them.

# ? Oct 18, 2011 03:14

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

SnoPuppy posted:

You probably get the muxes and logic for free if you're implementing it any modern, reasonable FPGA.
If you're using registers, you're consuming a slice and its LUTs regardless if you use them or not, due to the control sets and routing resources.

This whole discussion is exactly why whenever someone at work does something silly, I always, always, always ask them to draw out the schematic of what they're doing. If you can't figure out how to do roughly what you want with gates and FFs, you shouldn't be doing it.
Even if you do know how to implement it with logic and gates, you should still try to have an understanding of your specific part to make sure that the synthesizer wont do something dumb.

Remember that VHDL and Verilog are Hardware Description Languages - not magic, and you certainly don't write "programs" with them.

Quite true. I should point out that the LUTs in each slice can be used for "program" logic rather than unnecessary muxes - packing density is quite good. What exactly is magic about the example that I posted?

# ? Oct 18, 2011 04:20

SnoPuppy: Jun 15, 2005

Poopernickel posted:

What exactly is magic about the example that I posted?

That was more of a general comment, not directed at you specifically. Mainly for the XOR atrocity that was posted earlier.

I do think double buffering for the game of life would be pretty ridiculous - each element is the result of its neighbors, so you just have N identical copies of the same 9 to 1 boolean function and you only need 1 FF per game tile. I suspect the bigger problem will be routing congestion more than logic or FF use.

Or you could use a RAM and just iterate through each row in the game - it's basically a 3x3 kernel that's passed over the game tiles.

# ? Oct 18, 2011 08:00

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

SnoPuppy posted:

That was more of a general comment, not directed at you specifically. Mainly for the XOR atrocity that was posted earlier.

I do think double buffering for the game of life would be pretty ridiculous - each element is the result of its neighbors, so you just have N identical copies of the same 9 to 1 boolean function and you only need 1 FF per game tile. I suspect the bigger problem will be routing congestion more than logic or FF use.

Or you could use a RAM and just iterate through each row in the game - it's basically a 3x3 kernel that's passed over the game tiles.

Do you have any thoughts on build methodologies? I've been itching to move my builds out of Xilinx's dev environments over to something makefile-governed using their command-line tools.

# ? Oct 18, 2011 09:40

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

Poopernickel posted:

Do you have any thoughts on build methodologies? I've been itching to move my builds out of Xilinx's dev environments over to something makefile-governed using their command-line tools.

Source WebPack, then

code:

#!/bin/sh

# Minimal Xilinx build environment to show off the Nexys 2 programming
# script.

PROJ=led

# Choose the proper FPGA part ID.  Digilent ships two versions.
#PART=xc3s500e-fg320-5
PART=xc3s1200e-fg320-5

echo run -ifn $PROJ.v -ifmt verilog -ofn $PROJ.ngc -p $PART -top $PROJ | xst
ngdbuild -i -p $PART $PROJ.ngc
map -p $PART $PROJ.ngd
par $PROJ.ncd ${PROJ}_par.ncd $PROJ.pcf
bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf

There's another script that'll actually load the .bit file onto the nexys2, but the above should work if you just want to build.

# ? Oct 18, 2011 15:56

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

JawnV6 posted:

Source WebPack, then

code:

#!/bin/sh

# Minimal Xilinx build environment to show off the Nexys 2 programming
# script.

PROJ=led

# Choose the proper FPGA part ID.  Digilent ships two versions.
#PART=xc3s500e-fg320-5
PART=xc3s1200e-fg320-5

echo run -ifn $PROJ.v -ifmt verilog -ofn $PROJ.ngc -p $PART -top $PROJ | xst
ngdbuild -i -p $PART $PROJ.ngc
map -p $PART $PROJ.ngd
par $PROJ.ncd ${PROJ}_par.ncd $PROJ.pcf
bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf

There's another script that'll actually load the .bit file onto the nexys2, but the above should work if you just want to build.

Where do .ucf files figure in?

# ? Oct 18, 2011 17:07

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

Haven't been using them. For pin mappings I'm doing

code:

// synthesis attribute LOC led0 J14

in the .v files.

# ? Oct 18, 2011 17:21

Justus: Apr 18, 2006; ...

So, this isn't exactly Verilog-related, but maybe someone could point me in the right direction. I just started playing with a MachXO2 Pico (in addition to the control), and it has a 4char LCD on it. I've looked through the schematic, the datasheet, and the user guide, and I just can't seem to locate any relevant information except for the names of 12 pins (LCD_COM0 through LCD_COM3 and LCD_5 through LCD_12), and the fact (in the bill of materials) that it's a custom LCD made by phil@duerfeldtengineering.com for Lumex with a part number LCD-S401M16KR that I can't find a specific datasheet for.

I've tried various things with those pins through guesswork, but the best I've gotten is some garbage that shows up for half a second before fading out.

The board only comes with one demo, and it's a massive thing with dozens of different files and thousands of lines of code, with almost none of it commented at all, and I can't seem to find anyone else on the internet who's done anything with it (and has been kind enough to share code).

I know this probably isn't the right place to ask for help on my specific PLD. Where else can I ask? The Lattice forums are a ghost town!

# ? Oct 19, 2011 01:28

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

Justus posted:

except for the names of 12 pins (LCD_COM0 through LCD_COM3 and LCD_5 through LCD_12)
I've tried various things with those pins through guesswork, but the best I've gotten is some garbage that shows up for half a second before fading out.

What did you use that made it pulse for half a second? Do that. Repeatedly.

It's probably wired up such that COM0-COM3 is the common anode and 5-12 are routed to the individual cathode segments on all 4. So set all but one of COM to 1 and have the character bits on 5-12, then cycle through each COM being low and change 5-12. If this horrible description isn't clear, I have some old, lovely verilog demonstrating what I mean.

# ? Oct 19, 2011 02:16

Delta-Wye: Sep 29, 2005

Justus posted:

So, this isn't exactly Verilog-related, but maybe someone could point me in the right direction. I just started playing with a MachXO2 Pico (in addition to the control), and it has a 4char LCD on it. I've looked through the schematic, the datasheet, and the user guide, and I just can't seem to locate any relevant information except for the names of 12 pins (LCD_COM0 through LCD_COM3 and LCD_5 through LCD_12), and the fact (in the bill of materials) that it's a custom LCD made by phil@duerfeldtengineering.com for Lumex with a part number LCD-S401M16KR that I can't find a specific datasheet for.

I've tried various things with those pins through guesswork, but the best I've gotten is some garbage that shows up for half a second before fading out.

The board only comes with one demo, and it's a massive thing with dozens of different files and thousands of lines of code, with almost none of it commented at all, and I can't seem to find anyone else on the internet who's done anything with it (and has been kind enough to share code).

I know this probably isn't the right place to ask for help on my specific PLD. Where else can I ask? The Lattice forums are a ghost town!

I asked about this in the magic blue smoke thread a long time ago.

http://forums.somethingawful.com/showthread.php?threadid=2734977&pagenumber=15&perpage=40#post344104891

Ante's image is missing, but I can recreate it if you don't understand the gist. If you are already working on a PLD the XOR solution is very easy.

# ? Oct 19, 2011 03:07

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

JawnV6 posted:

What did you use that made it pulse for half a second? Do that. Repeatedly.

It's probably wired up such that COM0-COM3 is the common anode and 5-12 are routed to the individual cathode segments on all 4. So set all but one of COM to 1 and have the character bits on 5-12, then cycle through each COM being low and change 5-12. If this horrible description isn't clear, I have some old, lovely verilog demonstrating what I mean.

Is it some kind of 7-segment LED, or is it a character-driven LCD module?

Poopernickel fucked around with this message at 07:28 on Oct 19, 2011

# ? Oct 19, 2011 07:26

Justus: Apr 18, 2006; ...

JawnV6 posted:

What did you use that made it pulse for half a second? Do that. Repeatedly.

I thought of that. I tried having it refresh on a clock, but no dice. I think I've convinced myself that powering up the circuit is simply charging a capacitor enough for a split second to show something. I'm still thinking I'm gonna need to decipher the pinouts first.

quote:

It's probably wired up such that COM0-COM3 is the common anode and 5-12 are routed to the individual cathode segments on all 4. So set all but one of COM to 1 and have the character bits on 5-12, then cycle through each COM being low and change 5-12. If this horrible description isn't clear, I have some old, lovely verilog demonstrating what I mean.

I understand exactly what you mean, as this is precisely how the Cool Runner II CPLD board I used in school worked. I wish this one were so simple. Here's the code I'm using to try it out:

code:

always @ (posedge clk) begin
	case (Display)
		0		: LCD_encode = 1110;
		1		: LCD_encode = 1101;
		2		: LCD_encode = 1011;
		3		: LCD_encode = 0111;
		default	        : Display = 0;
	endcase
	Display=Display+1;
end
	
assign LCD_en = LCD_encode;
assign LCD = 00011001;

Poopernickel posted:

Is it some kind of 7-segment LED, or is it a character-driven LCD module?

It's an LCD module...but according to the spec, it's a 16-segment display...although I've also found it referred to as 7segment elsewhere.

EDIT: Theoretically, if this 4char display were as simple as the 7seg LEDs I used on the CoolRunner II, then this should display something - the same something - for all 4 characters.

Justus fucked around with this message at 17:32 on Oct 19, 2011

# ? Oct 19, 2011 17:15

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

Justus posted:

It's an LCD module...but according to the spec, it's a 16-segment display...although I've also found it referred to as 7segment elsewhere.

EDIT: Theoretically, if this 4char display were as simple as the 7seg LEDs I used on the CoolRunner II, then this should display something - the same something - for all 4 characters.

Have you worked through the reference design for the board? I glanced over it, and it looks like there's stuff in there which controls the LCD.

# ? Oct 19, 2011 18:16

Justus: Apr 18, 2006; ...

Poopernickel posted:

Have you worked through the reference design for the board? I glanced over it, and it looks like there's stuff in there which controls the LCD.

Well yeah, I looked through it...but being a beginner to this stuff, and the design not being notated, I couldn't really follow it. The LCD part of it is spread over about 5 or 6 of its several dozen different files, and it's hard to know how much of it is necessary to use the display, and which parts those would be.

# ? Oct 19, 2011 19:37

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

Did you read Delta-Wye's link? I'm not sure it's the same thing since they're talking about a single COM that appears to toggle with all the signal pins and your module looks like it's muxing somewhere. But at the very least try COM0 only and invert the signal pins when deasserting it, don't just leave them hardcoded.

If you can't tell if it's the board power on or your circuit causing the temporary flash, make something that holds off touching any of those until a button press.

Worst case, make a giant array in the demo project and record the pin values clock by clock. Think of it like cheap LA. Hopefully you have some way to get data off the chip and back to a PC in bulk, otherwise use LED's and a button to step through them :v:

# ? Oct 19, 2011 22:26

Justus: Apr 18, 2006; ...

So here's perhaps a more interesting question to get this thread back on track:

Anyone got any good resources or guides for writing simulation testbenches?

# ? Oct 25, 2011 22:26

Justus: Apr 18, 2006; ...

OK then, how about something a bit more specific, then.

I've managed to get some of my testbenches working now; is there a way to incorporate variables into the simulation other than port variables attached to pin outputs? I would guess not, since I don't see a way to instantiate the UUT in the testbench with any varible not in the port list...but I would think there should be a way, so I thought I'd ask. For instance, is there a way to add non-pin-assigned variables to the port list?

# ? Oct 26, 2011 22:10

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

Justus posted:

OK then, how about something a bit more specific, then.

I've managed to get some of my testbenches working now; is there a way to incorporate variables into the simulation other than port variables attached to pin outputs? I would guess not, since I don't see a way to instantiate the UUT in the testbench with any varible not in the port list...but I would think there should be a way, so I thought I'd ask. For instance, is there a way to add non-pin-assigned variables to the port list?

Yes, there is actually!

If you have some module you're trying to test out that looks like this:

code:

`timescale 1ns / 1ps
`default_nettype none

module butts(Clk_In, Signal_Out);

// I/O Declarations

    input Clk_In;
    output reg Signal_Out = 0;

// Local Variables

    reg buttface = 1;
    reg dumpy = 1;

// Assignments

    always @(posedge Clk_In) begin
        Signal_Out <= ~Signal_Out;
        buttface <= ~buttface;
    end
    
endmodule

you can access the internal variables as show below:

code:

`timescale 1ns / 1ps
`default_nettype none

module testblaster;

// Variables

    reg Clk_In = 0;
    wire Signal_Out;
    wire butt_monitor;

// Unit Under Test

    butts uutButt (
        .Clk_In(Clk_In), 
        .Signal_Out(Signal_Out)
    );

// Test Signals

    initial #0 forever #5 Clk_In <= ~Clk_In;
    
    assign butt_monitor = uutButt.buttface;
      
    initial begin
        #50;
        uutButt.dumpy <= ~uutButt.dumpy;
    end
      
endmodule

edit: This example works under the Xilinx ISE simulator, although I can't vouch for other simulators because we're a Xilinx shop here v :shobon:

v. This type of coding style isn't generally synthesizable, since most synthesizers operate on modules independently and optimize/remove registers.

double edit: You can also start functions and tasks which belong to instantiated modules using the same syntax.

Poopernickel fucked around with this message at 20:35 on Oct 27, 2011

# ? Oct 27, 2011 20:18

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

as for testbench guides, there are some good articles on ASIC World@

# ? Oct 27, 2011 20:19

Justus: Apr 18, 2006; ...

Wow, thanks dude! I think I've got a pretty good handle on simulation now! :cool:

# ? Oct 28, 2011 00:48

Adbot: ADBOT LOVES YOU

# ? May 5, 2024 15:29

Justus: Apr 18, 2006; ...

Does anyone know much about the Wishbone interface?

I think I understand that it's some kind of protocol I use in order to access hard-wired on-chip modules like SPI and I2C. I'm not making much of the reference designs so far. It almost looks as if it's simply a matter of naming registers the right things, but I know there's gotta be more to it than that.

# ? Oct 28, 2011 13:36

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

«‹›7 »