More Schematic tutorials?

[Altera_Forum]

Hi,  

Are there any more schematic tutorials aside from http://www.altera.com/education/training/courses/odsw1105 I am thinking i'll need to find my basic digital logic books. but it would be nice to have some on this website.

[Altera_Forum]

I got this. I have enough, but I figure at least this would get me started with dataflow designs. 

http://www.amazon.com/rapid-prototyping-digital-systems-quartus%c2%ae/dp/0387277285/ref=sr_1_2?ie=utf8&qid=1388561822&sr=8-2&keywords=altera+schematic

[Altera_Forum]

The reviews of that books are really poor.  

Schematic design is not the best way to learn - it is little used and of no use in the working world. It may help you understand concepts but thats about it.  You're much better off learning either VHDL or Verilog.

[Altera_Forum]

I'd like to comment on what I perceive as a common misconception in the "schematic vs HDL" design entry debate. That is, you must choose between one or the other. Contrary to Tricky's assertion of "no use in the working world", many people, myself included, prefer to do our top level designs in schematic or block diagram form, and then code each of the top level blocks in HDL. Why? Because a top level design in block diagram form can give an instant picture of the overall system architecture as well as a clear view of the signal flow through the various processing blocks. You can perceive in minutes (or less) what might take hours pouring over a text based top level entry. I'm dumbfounded why more people don't take this approach, though they must have their reasons. Imagine, though, that you asked someone for a (hardware) schematic of a board you were working on and they handed you a netlist. What would your response be? 

 In fairness to Tricky I will agree that if by "schematic design" you mean designing your logic with gates, counters and all manner of old-style 7400 series devices then this mode is outdated, irrelevant and has no place in modern digital system design.

[Altera_Forum]

Sorry - yes, schematic design at the top level can help visualise the system. But thats about it. Without understanding of a HDL (VHDL or Verilog only) you wont have much use out there. 

 I have had to fix designs created 95% in schematics. And poorly documented schematics at that. It wasnt much fun.

[Altera_Forum]

I've seen (some brilliant) people create fairly complex systems with schematic capture. It can be done. If I can write VHDL and save It as a schematic in my library for later use, 

I think it would be worth doing.

[Altera_Forum]

--- Quote Start ---  Sorry - yes, schematic design at the top level can help visualise the system. But thats about it. Without understanding of a HDL (VHDL or Verilog only) you wont have much use out there.  I have had to fix designs created 95% in schematics. And poorly documented schematics at that. It wasnt much fun.  --- Quote End ---    That doesn't sound fun...I don't know if the documentation features are limited, but I don't have a problem with writing docs about my designs either

[Altera_Forum]

with that said. I just want to be able to create modules well in VHDL and have a library of modules that I can easily string together. Components in VHDL get a bit confusing. It may be the lazy way out but I also feel it's a constructive way of visualizing things. I don't expect that book to take me very far, but I'm interested in seeing how much it can teach me about Quartus II itself. since I've not learned very much from the Altera Labs. The countless hours I've spent grinding through making simple components from gates has taken its toll on my willingness to follow them, especially since I have to go back and look at those labs for reference.. :(

[Altera_Forum]

My 5c on schematics versus HDL. 

 If you're serious about creating systems using HDL, then those systems *MUST* have an associated testbench.  Schematic capture is tool specific, i.e., Quartus.  To simulate your design in Modelsim, you need a testbench (typically written in HDL), and an instance of your top-level design. During simulation you will typically save a waveform file so that you can visualize your design. The waveform node names are hierarchical, and represent a path into your design.  If your top-level is a schematic, then you have to convert that to HDL to simulate. I doubt the HDL Quartus generates for a top-level design is particularly readable.  Using a top-level schematic makes it very difficult to automate running all testbenches for a system, eg., lets say all project code is in a code versioning system, and I have machine setup to checkout all code, and run the testbenches. If the code is in pure HDL, then the testbenches can all be built and run in Modelsim. If however there are top-level schematics, then Quartus first needs to be run to generate HDL versions of the top-level, and then Modelsim run to simulate.  I personally prefer all code in an HDL language. Since Modelsim-ASE (Altera Starter Edition) only supports single language simulation, I try to stick with a single language, eg., VHDL or SystemVerilog, for tutorials or anything I want to give to someone else, as that way they can use free tools.  Its also very difficult to track changes using a code versioning system with schematic drawings. With HDL you can simply perform a difference between two text files.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  My 5c on schematics versus HDL.  If you're serious about creating systems using HDL, then those systems *MUST* have an associated testbench.  Schematic capture is tool specific, i.e., Quartus.  To simulate your design in Modelsim, you need a testbench (typically written in HDL), and an instance of your top-level design. During simulation you will typically save a waveform file so that you can visualize your design. The waveform node names are hierarchical, and represent a path into your design.  If your top-level is a schematic, then you have to convert that to HDL to simulate. I doubt the HDL Quartus generates for a top-level design is particularly readable.  Using a top-level schematic makes it very difficult to automate running all testbenches for a system, eg., lets say all project code is in a code versioning system, and I have machine setup to checkout all code, and run the testbenches. If the code is in pure HDL, then the testbenches can all be built and run in Modelsim. If however there are top-level schematics, then Quartus first needs to be run to generate HDL versions of the top-level, and then Modelsim run to simulate.  I personally prefer all code in an HDL language. Since Modelsim-ASE (Altera Starter Edition) only supports single language simulation, I try to stick with a single language, eg., VHDL or SystemVerilog, for tutorials or anything I want to give to someone else, as that way they can use free tools.  Its also very difficult to track changes using a code versioning system with schematic drawings. With HDL you can simply perform a difference between two text files.  Cheers, Dave  --- Quote End ---    there's no doubt in my mind that there are and will be many limitations to my designs when writing Schematics. Honestly, it looks like it's barely even supported. I just feel that I've put countless hours into VHDL and have gotten nowhere, and I know that I've achieved great things with schematic-based designs on other platforms. I'm hoping that a mix of the two will help me to eventually get a better understanding of HDLs eventually, and digital hardware design for that matter.

[Altera_Forum]

--- Quote Start ---  there's no doubt in my mind that there are and will be many limitations to my designs when writing Schematics.    --- Quote End ---   Ok, good to hear you understand the tradeoffs.    --- Quote Start ---   Honestly, it looks like it's barely even supported.   --- Quote End ---   Don't worry, you'll find features of HDL languages that are not supported in Quartus too :)    --- Quote Start ---   I just feel that I've put countless hours into VHDL and have gotten nowhere   --- Quote End ---   Perhaps you should ask more questions when you get stuck. If you create code, a testbench, and clearly describe what you are failing to grasp, then the readers of this forum are fairly helpful. If you simply post code that will not even compile, along with too vague a question, eg., "Help, I can get this to compile", usually will not get a response, since its usually because "You're too lazy to read the error messages". If you take the time to ask an intelligent question, you will get intelligent responses.  Cheers, Dave

[Altera_Forum]

--- Quote Start ---  Ok, good to hear you understand the tradeoffs.   Don't worry, you'll find features of HDL languages that are not supported in Quartus too :)   Perhaps you should ask more questions when you get stuck. If you create code, a testbench, and clearly describe what you are failing to grasp, then the readers of this forum are fairly helpful. If you simply post code that will not even compile, along with too vague a question, eg., "Help, I can get this to compile", usually will not get a response, since its usually because "You're too lazy to read the error messages". If you take the time to ask an intelligent question, you will get intelligent responses.  Cheers, Dave  --- Quote End ---   Yes, This forum is good with responses to half-intelligent questions, I appreciate that. Sometimes, I'm just completely clueless on how to even approach a problem in VHDL and the building block style of schematic seems like an easier way to go about it.

[Altera_Forum]

--- Quote Start ---  Sometimes, I'm just completely clueless on how to even approach a problem in VHDL and the building block style of schematic seems like an easier way to go about it.  --- Quote End ---    I'll typically draw a block diagram with counters and data path logic, then draw the waveforms that logic needs to work, and then start writing an HDL design along with its testbench. I then "fill in the details" by adding new test sequences, and adding FSM states and datapath controls until the logic is correct. For example, read through this document ...  http://www.ovro.caltech.edu/~dwh/correlator/pdf/ftdi.pdf  Cheers, Dave

[Altera_Forum]

I'll give it a read. hopefully I can take something interesting away from this.

[Altera_Forum]

--- Quote Start ---  I'll give it a read. hopefully I can take something interesting away from this.  --- Quote End ---   You could also try and come up with an HDL design that you think is interesting, or is useful to you, and come up with a "design description", post that along with how you think you'd implement it either in HDL or a schematic. The ultimate goal would be to simulate the design in Modelsim as well as synthesize it in Quartus (along with pin and timing constraints). That'll give you a "real-world" reference design that is meaningful to you. Once you have your first design, and an appropriate design sequence, others will follow much easier.  Cheers, Dave

[Altera_Forum]

well, a useful design to me would be learning how to interface with the audio codec of my DE2, and outputting waveforms. I guess I could "blog" about it in a forum thread?

[Altera_Forum]

--- Quote Start ---  well, a useful design to me would be learning how to interface with the audio codec of my DE2, and outputting waveforms.  --- Quote End ---    That sounds like a reasonable goal. Looking at the DE2 schematic, the audio interface is a WM8731, and it shows an I2C interface, and some serial interfaces for the audio input and output.  So, to start with you need to decide how you are going to access the I2C bus, and where your software to control that I2C interface will reside, eg., on the FPGA in a NIOS II processor, or externally on your PC. My personal preference is to initially test my hardware interfaces via code running on my PC using the JTAG-to-Avalon-MM interface.  The Wiki has information on using the OpenCores I2C controller  http://www.alterawiki.com/wiki/i2c_%28opencores%29  (I have not tried this particular controller)    --- Quote Start ---  I guess I could "blog" about it in a forum thread?  --- Quote End ---   I'd recommend writing a tutorial and posting it to the AlteraWiki where others can more easily locate it. I personally prefer a PDF tutorial document and a zip file containing code, rather than a stream-of-consciousness blog ...   Take a look at this tutorial here:  http://www.alterawiki.com/wiki/using_the_usb-blaster_as_an_sopc/qsys_avalon-mm_master_tutorial  It needs to be revised for 13.1, however, the Quartus Qsys procedure is still pretty much the same, its just the simulation that has changed slightly.  Cheers, Dave

[Altera_Forum]

Thanks,  

I have a bit of learning to do, particularly with I2C. I'll probably start with learning the I2C interface before I write any tutorials. Hopefully this could get me started: http://www.fpga4fun.com/i2c.html Thanks for your input. I'll start learning right away.   -edit- Just chiming in, I really like this one. the code seems to be really understandable. I'll give it a few reads. Looks like I won't have many problems learning I2C!! : http://hamsterworks.co.nz/mediawiki/index.php/i3c2

[Altera_Forum]

Note how much "easier" it is to learn when you have a well-defined goal.  

 One of your objectives with these controllers should be to create a simulation. There are simulation models of I2C EEPROMs, so its easy enough to find an I2C device to talk to.  Cheers, Dave