How do I split a bus into individual signal lines?

Thanks. That seemed to work. Its just not very intuitive the way they do it like that. The help files sent me all over the place looking for a secret icon to click so I could bring up the node name editor.

It looks good on the screen, but it will be a few days before I can connect everything well enough to compile it to see if it actually works. I will post the results then.

UPDATE: The design compiled and worked fine. Thanks again. Clicking and then simply typing the node name (with no prompts) worked fine. Its easy to do once you know how. Kind of like an Easter egg. I have no idea why Altera wants to confuse people with complicated instructions that don't work.

I had a similar experience trying to figure out how to make a logic symbol out of a schematic block. Again, the altera instructions sent me off in multiple wrong directions. I came across an EDU site that explained how to do it correctly in three clicks: FILE->Create->Symbol file from current file

Anyhow, I'm glad this place is here to help explain things to people like myself who are not familiar with the software yet.

It does seem that a lot of people are going HDL.

I like schematic design because its easy for me to debug. I can just look at it and tell what its doing and what's wrong. I'm sure other people can do the same with HDL, but not me. I know HDL has several advantages, but one thing I did notice is that the HDL version of my project (done by others) took about 4X as many LE's as my schematic version did. The schematic version consisted entirely of logic primitives and TTL blocks so I didn't do any intensive optimizing.

That said, my next task is to figure out how to import HDL blocks into a schematic. Some of the Altera library components are HDL blocks so I know it can be done. I am thinking it is similar to the way its done with schematic blocks, but we'll see.

--- Quote Start ---

It does seem that a lot of people are going HDL.

--- Quote End ---

Since I started in FPGA land 10 years ago schematics were frowned upon.

--- Quote Start ---

I like schematic design because its easy for me to debug. I can just look at it and tell what its doing and what's wrong. I'm sure other people can do the same with HDL, but not me. I know HDL has several advantages, but one thing I did notice is that the HDL version of my project (done by others) took about 4X as many LE's as my schematic version did. The schematic version consisted entirely of logic primitives and TTL blocks so I didn't do any intensive optimizing.

--- Quote End ---

This really comes down to the designer. Im sure it would work just as well in HDL as in schematic if it was done properly.

Im sure youre design was very clever and worked well, but would someone else have understood it? I have never seen a well commented schematic, and while I have seen some terrible code, I would rather work out whats going on from poorly commented code than a schematic. I have spent weeks trying to understand and fix someone elses terrible (and undocumented) schematics - they had links crossing all over the place, with named association spanning vast distances across pages. How am I meant to find a bug in that?

So - for me:

Pros:

- It can look neat at a higher level

Cons:

- Cannot be used with version control (you get no visualisation of changes over time)

- Cannot be directly simulated (you need a netlist or convert to HDL to simulate)

- Easily becomes a mess

- not easy to add comments

At the end of the day - without HDL knowledge, your job market is going to be severely limited, if not non-existant.

I'm actually an embedded software engineer so any hardware design is a plus and not usually a requirement. In any case, I would disagree about the version control on schematics because they are just text files and you can look at them using Notepad. I wouldn't recommend editing them that way, but any text file can be added to a version control system. However, if you are talking about a system that highlights the differences in a graphical format, then that's a different matter.

I first did FPGA's in the late 90's using Xilinx. HDL was in its infancy back then and usually cost a lot extra since it was an add-on to the main license (which wasn't free back then). The lead EE where I worked switched my design to Altera (I'm software), but I've never used Altera myself until now. We used Flex 10K's on our production boards back then.

I'll probably start working with HDL at some point, but right now I'm sticking with what I know. I am getting fair at reading it, but writing it is more difficult.

I think any design can be messed up by someone trying to be clever with the design. I make schematics the same way I write code - in modules with no implicit linkage to anything else. The only exception is Gnd and Vcc. If there is no pin, there is no connection. I don't use named wires for the reasons you mentioned.

The HDL code that the other guy wrote who did the same project seemed sloppy, but since I'm not a verilog expert, I can't say for sure. In my schematic design, I created a single main counter/divider for all the little clocks that are used in the design. In his HDL design, he just passes the main 48M clock to everything and all the circuits just have their own private 32 bit dividers to get the frequency they want. It doesn't seem all that efficient, but then again, you never know how the optimizer is going to handle it.

So for right now, I picked up a Cycone IV E board and am playing with it. I'm not sure how far 6000 LE's will go, but the ultimate goal is to make an IBM PC VGA compatible controller. Its actually rather complicated considering all the different video modes and that they all work differently. Too complex for TTL logic. If it was just plain jane VGA, I could just do that with a PIC or AVR or something.

Anyhow, right now I'm just learning the basics of the Altera software.

--- Quote Start ---

I'm actually an embedded software engineer so any hardware design is a plus and not usually a requirement. In any case, I would disagree about the version control on schematics because they are just text files and you can look at them using Notepad. I wouldn't recommend editing them that way, but any text file can be added to a version control system. However, if you are talking about a system that highlights the differences in a graphical format, then that's a different matter.

--- Quote End ---

The main problem is that if you move an item, and the circuit does not change, the .bdf file changes. Plus, reading the file to see what has actually changed is not trivial.

--- Quote Start ---

I make schematics the same way I write code - in modules with no implicit linkage to anything else.

--- Quote End ---

This should also be the philosphy behind HDLs.

I highly recommend you get on with learning an HDL. If you're confident with logic there is no need for schematics, and you can build some powerful testbenches.

I'll probably complete this design with schematics and then migrate each module to HDL one at a time. There are a lot of things I don't know about HDL. Take the following counter code (one of many from the other guy):

reg cnt;
always @(posedge clk)
	begin
		cnt = cnt + 1'b1;
	end

So common sense tells me that this is a 32 bit counter - but is that an asynchronous or synchronous counter? In my schematic design, I just used simple ripple counters because I didn't need synchronous for a clock divider.

And does the software implement the above "+" sign as a counter or as a 32 bit adder with full carry look ahead? Would "cnt = cnt + 3'b101;" work? Mathematically speaking, adding 1 to a number is a counter, but electronically, adders are considerably more complicated and are going to suck up more LE's on the chip.

--- Quote Start ---

So common sense tells me that this is a 32 bit counter - but is that an asynchronous or synchronous counter? In my schematic design, I just used simple ripple counters because I didn't need synchronous for a clock divider.

--- Quote End ---

Its a synchronous counter, because the addition occurs on the rising edge of the clock.

And can I stop you before you carry on down your asynchronous path - FPGAs are designed to be synchronous. Ripple counters, logic generated clocks etc are a bad idea inside an FPGA. The delays and skew in the clocks will be dependant on the P&R and also PVT. So what works one time may not work the next time you compile it, or when it gets hot etc. And you cannot perform timing analysis on an asynchronous design.

So it is highly recommended you use the same clock as much as possible and generate clock enables to divide any clock - not ripple counters or logic generated clocks.

--- Quote Start ---

And does the software implement the above "+" sign as a counter or as a 32 bit adder with full carry look ahead? Would "cnt = cnt + 3'b101;" work? Mathematically speaking, adding 1 to a number is a counter, but electronically, adders are considerably more complicated and are going to suck up more LE's on the chip.

--- Quote End ---

It will be a 32 bit adder with full carry look ahead because thats what the code asked for - and how the FPGA is optimised. The luts in the FPGA all have a high speed carry chain exactly for this purpose.

And yes, cnt = cnt + 3'b101 would also work just fine, the same way, and probably just as fast as 1'b1.

With devices as they are now, logic is not usually the limiting factor in designs - the problems usually come with lack of RAMs, DSPs or routing resources.