Yet another question on scopes :)

[llaith]

Hi Guys,

I came across Dave and his youtube series a few months ago, as a Aussie in brit-land, a friend pointed me at him knowing I was feeling a little homesick and somewhat interested in electronics (I started a degree in digital electronics 25+ years ago but changed to software development), and i've had a career in software development since. Anyway, a few months of enjoying the talks, particularly the retro teardowns, and with influence from that same friend, I'm starting to get into FPGAs.

So I have roadmap for myself I'm following:
   1) I bought some basic kit and started with a refresher on basic electronics (mostly done)
   2) I'm about to start following along and build a breadboard 8 bit computer like here: .
   3) I've also bought a Diligent Arty A7 board and a uni text book on cpu design in VHDL & Verilog https://www.amazon.co.uk/Digital-Design-Computer-Architecture-ARM/dp/0128000562 (thats the attraction of  FPGAs to software developers)
   4) Then I plan to experiment with implementing entire retro chipsets on the FPGA, such as C64 and TRS-80 (machines I had growing up)
   5) Final stage will be using this knowledge gained (over probably the next 3 - 5 years) to start playing around with IoT devices, (I have some ideas around listening in and performing data acquisition and analytics on what our IoT devices are reporting about us).

So where I find myself, now I am looking at the breadboard computer stage (i inserted that recently between stages 1 & 3) is I am feeling the lack of an oscilloscope. Cost is a big issue because my partner hasn't 'bought in' to my new hobby so I am looking for an inexpensive way to do only what I need. I've read heaps of other discussions on here, and I can tell that the answer to that question is really dependent on what is the intended use of the scope, hence I've outlined my roadmap above and I'll explain what I am looking for:

Initially, I am looking for something cheap that will server to help diagnose the kinds of digital issues I will come up against building and debugging the breadboard computer (stage 2). I foresee that I will be particularly interested in debugging the effects of the clock steps as that is the crux of what I am interested in (how to use latches to implement logic inside the cpu), so some kind of way to record a stream of transitions? Is this more logic analyser stuff? I find myself really confused about how many channels, and how much max bandwidth and storage memory. Can anyone point me in the direction I want to look for this? I don't mind a USB device for this stage, although the pico analyser I found references to in this forum is quite expensive and probably overkill (do i need 4 channels and MSO?).

Secondly, probably when I get to the end of stage 4 (retro computer), and certainly when I am on stage 5 (data-acquisition IoT devices), I will be starting to want to control devices with the FPGA, I assume though interfaces like SPI (stage 5) and joystick and ROM-cartridge expansions (stage 4), and other such interfaces. I assume I will need a similar ability to see the data on the buses but much faster, so presumably this would be another category of devices? Can anyone point me in the direction I should look for this kind of device? I'll keep an eye out in advance of the need for it in the hopes that something pops up in the second hand market.

It's ok if these are two devices, it's almost certainly preferable as it will probably keep the cost down in the initial stages where my wifey would be more likely to moan

Any answers or comments much appreciated.

Cheers

[rstofer]

Short answer:  Digilent Analog Discovery 2
https://store.digilentinc.com/analog-discovery-2-100msps-usb-oscilloscope-logic-analyzer-and-variable-power-supply
You can read about it at Digilent and Dave has done a review of the device (I don't recall which version) plus there are a ton of videos on YouTube.  I'm not going to get into it except to say that it is really a complete lab in a box.  Do not make the common mistake of taking it for a toy and just giggling.  There are situations where it is my preferred way of doing experiments.  Just look at the number of instruments it can become.  If you're interested in electronics at a low level, like filters and amplifiers, the AD2 is a great tool!

For that 8 bit Ben Eater CPU, you can single step the clock and there are a bazillion LEDs, a logic analyzer isn't required nor is a scope.

That ARM project is going to be quite a leap,  I would suggest you Google for 'lc-3' (not the newer 'lc-3b') and implement the core in your Arty.  Given that Xilinx Vivado has an Internal Logic Analyzer, there isn't much need for an external unit.

That said, the Arty wouldn't be my first choice because it doesn't have gadgets like a host of switches, buttons, LEDs and 7-Segment Display.  I prefer the Nexys 4 DDR board but I'll concede, it is a lot more expensive.  Anyway, the LC-3 project comes with an assembler and C compiler so it's fairly useful.

Unless you are really into doing retro chip stuff, I would even consider writing the VHDL for that Ben Eater 8 bit CPU and stuffing it into the Arty.

Many universities are using the LC-3 project for one of their computer architecture courses.  Everything you need is on the Internet from multiple sources.  There is also a textbook "Introduction to Computing Systems" Second Edition by Patt and Patel.  This is a truly great project!

The reason I am steering clear of the 'b' version is that I don't know if the compiler and assembly have been changed to accommodate the new addressing scheme.  There's a lot to learn from the original 16 bit version.

The prevailing low $ scope is the Rigol DS1054Z - details all over this site.  The newer version from Siglent like the SDS1102X-E or, better, the SDS1104X-E are reasonably priced.  I have the Rigol and am thinking about the SDS1204X-E at some point.

[rstofer]

Bus decoding is a nice feature on a scope as long as the amount of data is limited.  Some scopes only decode what you can see on the screen so you are limited to, perhaps, a single transaction with limited data.

Logic analyzers are used for decoding long streams of data but this is a massive time sink.  What are you going to do with a million clocked events?  You need to think about how to get to the answer before retirement kicks in.  One way is to pick a trigger, even if you have to gin one up in logic, so that you start recording at exactly the right clock cycle.

For the LC-3 project, there are less than 64 states and I would be working on only a small subset (one instruction) so debugging with LEDs and 7-Segment Displays is easy.  Even when I did a much larger project with the help of an external logic analyzer, I partitioned the problem in such a way that a single 32 channel Logic Analyzer was adequate.  I wouldn't want a LA with much less than 32 channels and it would absolutely need a state clock input.

At Opencores.Org, you will find a T80 core which is a very faithful implementation of the Z80.  I have used it as a basis for running CP/M 2.0 and as a CPU for PacMan (which is where I first ran across it).  It should fit easily in that Arty board.  The question is whether the board has enough IO when it comes time to add a Compact Flash device for the disk memory (CP/M).  The original Spartan 3 Starter  Board had plenty!  Alas, these boards are gone.  You could use an SD card and there are plenty of cores for doing this.  I have always thought that SD cards are a PITA.  The Compact Flash looks like a set of addressable registers.

On the issue of using the AD2, the logic analyzer portion is 5v tolerant.  This is a big deal if you plan to use old TTL chips with modern 3.3V gadgets.

Four channels is helpful when decoding SPI because there are 4 signals.  Other than that, I got by with 2 channels for decades and I only bought the DSO because I wanted to see how they worked.  My old Tektronix 485 350 MHz 2 channel scope was more than adequate.

Dave isn't a big fan of MSO scopes, he has a video on this.  I have never had one so what do I know?  Well, I know I haven't needed one...

[llaith]

Thanks rstofer, I really appreciate the well-thought-out answer, and you managed to answer a lot of other questions I had also!

> Short answer:  Digilent Analog Discovery 2
Ok, I have heard of this during my research. I kinda thought it was a bit 'pro', but I'll start putting the money aside. I'll look for Dave's review.

> For that 8 bit Ben Eater CPU, you can single step the clock and there are a bazillion LEDs, a logic analyzer isn't required nor is a scope.
Ahh, very interesting... I did wonder about that... I wasn't sure if the led's would be enough. I was completely blown away by: https://monster6502.com/ which is one of the reasons behind my interest. I wasn't sure if there were times I would find reading the LEDs annoyingly slow compared to looking at a bit pattern of high/lows on some sort of scope/analyser. It's sound from your reply like the LEDs will be enough. Cool.

>That ARM project is going to be quite a leap,  I would suggest you Google for 'lc-3' (not the newer 'lc-3b') and implement the core in your Arty.  Given that Xilinx Vivado has an Internal Logic Analyzer, there isn't much need for an external unit.
Ahh, I read somewhere the Vivado has an analyzer that can be put into the 'logic fabric' (if that's the right term) but couldn't see any examples yet on youtube. I'm sure that being the case, it will be more than enough for the near future.

I googled LC-3 and if it's this one (https://en.wikipedia.org/wiki/LC-3) then it does look really interesting. I'm very happy to follow along the path set out for students by the experts The fact that it can be targetted by a C compiler is a big bonus, I kind of resigned myself to using (at best) assembly for almost all of the coding, if not simple machine code! I think I'll look into this as an intermediate between the Ben Eater 8-bit and the ARM book

Also, I know the ARM project is quite a leap, however I did the first couple of years of electronic engineering at uni where we went into how all the bits of an 8086 motherboard was put together (although we didn't go into the CPU itself). Later when I changed to software I did a reasonable amount of assembly programming, and later direct machine code entry into embedded Motorola 68000 cpus, something I did actually use now and then in the first couple of years out of uni, so i'm feeling fairly hopeful i'll have enough context and motivation to be able to follow the book. I've been playing with Verilog and VHDL (a few hours) and it's really fun (I prefer VHDL, reminds me of the Ada/Modula2 code I did at the start of my career!).  I've also got some other arm dev boards and i've been working my way through some Udemy courses on writing linux drivers for embedded systems, so choosing the ARM version of that book vs the MIPS version should hopefully give me some additional insight on working with ARMs as a nice side effect.

> That said, the Arty wouldn't be my first choice because it doesn't have gadgets like a host of switches, buttons, LEDs and 7-Segment Display.  I prefer the Nexys 4 DDR board but I'll concede, it is a lot more expensive.  Anyway, the LC-3 project comes with an assembler and C compiler so it's fairly useful.
I played with the arduino over the last year, and I've kind got the leds and switches out of my system for now... playing with the 555 timers, etc. Having said that, I know I am trying to go from toddling along to entering a marathon, so I am expecting it to involve some tumbles along the way. I may end up stepping back and spending more time with the basics. I did grab some pmods for the board, such as a vga, ps2, and audio jacks. I figure I'll do the usual vga-adapter in fpga examples along the way, and they'll be useful with the retro computing stuff, even if i need a dev board with a bigger fpga chip, as long as I get one that supports pmods.

>Unless you are really into doing retro chip stuff, I would even consider writing the VHDL for that Ben Eater 8 bit CPU and stuffing it into the Arty.
Ahh... that's an *excellent* idea! I don't know why that didn't occur to me, that's the perfect intro to VHDL, rather than jumping straight into the ARM book. Thanks!

>Many universities are using the LC-3 project for one of their computer architecture courses.  Everything you need is on the Internet from multiple sources.  There is also a textbook "Introduction to Computing Systems" Second Edition by Patt and Patel.  This is a truly great project!
Okay, I've found a copy on amazon, ordered. Thanks!

>The prevailing low $ scope is the Rigol DS1054Z - details all over this site.  The newer version from Siglent like the SDS1102X-E or, better, the SDS1104X-E are reasonably priced.  I have the Rigol and am thinking about the SDS1204X-E at some point.
Ok, I saw that mentioned in similar-ish posts from a while back, I just wasn't sure if that applied to my mainly digital-only interests, I'll take this as the definitive answer.

>Bus decoding is a nice feature on a scope as long as the amount of data is limited.  Some scopes only decode what you can see on the screen so you are limited to, perhaps, a single transaction with limited data.
>Logic analyzers are used for decoding long streams of data but this is a massive time sink.  What are you going to do with a million clocked events?  You need to think about how to get to the answer before retirement kicks in.  One way is to pick a trigger, even if you have to gin one up in logic, so that you start recording at exactly the right clock cycle.
Ahh, I had exactly these concerns. I saw some demo where someone was putting in the exact sequence to trigger the start of a capture, and this has to be the only way to make sense of it right? Interesting that it's possible to gin one up in logic? By that do you mean adding some logic in the actual FPGA that watches and waits for the right pattern on the internal bus then starts logging it out? Makes sense, but I hadn't thought of that. Seems like a pretty powerful technique. I assume these kinds of tricks and tips i'll find in the student manuals or these kinds of forums? I do have a couple of people around me at work with FPGA knowledge (by luck!), but that might change if I move on elsewhere.

>For the LC-3 project, there are less than 64 states and I would be working on only a small subset (one instruction) so debugging with LEDs and 7-Segment Displays is easy.  Even when I did a much larger project with the help of an external logic analyzer, I partitioned the problem in such a way that a single 32 channel Logic Analyzer was adequate.  I wouldn't want a LA with much less than 32 channels and it would absolutely need a state clock input.
Hmm, I can't visualise exactly what you mean here. Is this because you were working with 32 bit wide data paths? I expect to be with 8 bit wide ones for a while yet, does that mean I shouldn't bother with a LA with only 8 channels because I won't really need it for the simpler experiments, and when I get to the point I need it I should get a 32 channel one?

>At Opencores.Org, you will find a T80 core which is a very faithful implementation of the Z80.  I have used it as a basis for running CP/M 2.0 and as a CPU for PacMan (which is where I first ran across it).  It should fit easily in that Arty board.  The question is whether the board has enough IO when it comes time to add a Compact Flash device for the disk memory (CP/M).  The original Spartan 3 Starter  Board had plenty!  Alas, these boards are gone.  You could use an SD card and there are plenty of cores for doing this.  I have always thought that SD cards are a PITA.  The Compact Flash looks like a set of addressable registers.
> On the issue of using the AD2, the logic analyzer portion is 5v tolerant.  This is a big deal if you plan to use old TTL chips with modern 3.3V gadgets.
> Four channels is helpful when decoding SPI because there are 4 signals.  Other than that, I got by with 2 channels for decades and I only bought the DSO because I wanted to see how they worked.  My old Tektronix 485 350 MHz 2 channel scope was more than adequate.
Interesting, I'll store these tips away for later access, thanks

Building a PacMan is a pretty cool project! I remember those arcade games (and arcades for that matter!). If being able to build something like that doesn't get my daughter interested in engineering, probably nothing will!

> Dave isn't a big fan of MSO scopes, he has a video on this.  I have never had one so what do I know?  Well, I know I haven't needed one...
Thats a really good tip, because that was one of the big questions I had. People on these forums seem to have both opinions, but if it's possible to work without them for years, then it must be a luxury right? Hmm, now you mention it I seem to recall someone pointing out they used to be niche products, so that fits with your experience, good to know.

Thanks man, that's a lot of really helpful information! Particularly thanks for the point in the LC-3 direction, I'll definitely chase that up.

Cheers!

[rstofer]

> For that 8 bit Ben Eater CPU, you can single step the clock and there are a bazillion LEDs, a logic analyzer isn't required nor is a scope.
Ahh, very interesting... I did wonder about that... I wasn't sure if the led's would be enough. It's sound from your reply like the LEDs will be enough. Cool.

Sure, reading LEDs is slow.  But so is everything else!  As you get along with this stuff, you will develop your own way of debugging.  On the Ben Eater project, the LEDs are sufficient as long as the clock runs slow enough or you use the 'single-step' feature.  I used to do this kind of thing back in the mid '70s on an Altair 8800 (Intel 8080 based).  I did just a wee bit of it on the IBM 1130 (details at www.ibm1130.org).
The Analog Discovery 2 might be a help.

>That ARM project is going to be quite a leap,  I would suggest you Google for 'lc-3' (not the newer 'lc-3b') and implement the core in your Arty.  Given that Xilinx Vivado has an Internal Logic Analyzer, there isn't much need for an external unit.
Ahh, I read somewhere the Vivado has an analyzer that can be put into the 'logic fabric' (if that's the right term) but couldn't see any examples yet on youtube. I'm sure that being the case, it will be more than enough for the near future.

> That said, the Arty wouldn't be my first choice because it doesn't have gadgets like a host of switches, buttons, LEDs and 7-Segment Display.  I prefer the Nexys 4 DDR board but I'll concede, it is a lot more expensive.  Anyway, the LC-3 project comes with an assembler and C compiler so it's fairly useful.
I played with the arduino over the last year, and I've kind got the leds and switches out of my system for now...

In terms of FPGA projects, I think you are underestimating the difficulty in debugging logic inside a chip running at 50 or 100 MHz (or even higher).  For the way I debug, I want to bring out certain values.  I might want the PC, Acc, Flags, ginned up debugging signals, and so on.  On my IBM1130 project, I built an external board with 4 banks of 4 digit 7-Segment displays plus I used every LED and switch on the board itself.  Then I added a 32 bit port for the logic analyzer.

Since the system had 16 console entry switches, I also implemented a hardware breakpoint.  This was invaluable!  It's real easy to talk about building up an emulation but it's orders of magnitude more complex when you have to run the factory software, unchanged.  Why isn't the system booting?  This is not a trivial question when you have to paw through both hardware and 50 year old OS assembly language source code to find the answer.

For the LC3 project I created an 8 input MUX to send values to the displays and used 3 switches to select the variable:  Debug Out (some random logic I wanted to see), PC, MAR, MDR, InterruptPriority, PSR, Register Load Signals, Addr2muxOutput and PCadderOutput.  In addition, I used all 16 LEDs, all 16 Switches an the 5 buttons.  There are NEVER too many gadgets when it comes time to debug.

A single step clock is always useful.

The Vivado Internal Logic Analyzer will be a tremendous help - once I learn how to take advantage of it.

>Bus decoding is a nice feature on a scope as long as the amount of data is limited.  Some scopes only decode what you can see on the screen so you are limited to, perhaps, a single transaction with limited data.
>Logic analyzers are used for decoding long streams of data but this is a massive time sink.  What are you going to do with a million clocked events?  You need to think about how to get to the answer before retirement kicks in.  One way is to pick a trigger, even if you have to gin one up in logic, so that you start recording at exactly the right clock cycle.
Ahh, I had exactly these concerns. I saw some demo where someone was putting in the exact sequence to trigger the start of a capture, and this has to be the only way to make sense of it right? Interesting that it's possible to gin one up in logic? By that do you mean adding some logic in the actual FPGA that watches and waits for the right pattern on the internal bus then starts logging it out? Makes sense, but I hadn't thought of that. Seems like a pretty powerful technique. I assume these kinds of tricks and tips i'll find in the student manuals or these kinds of forums? I do have a couple of people around me at work with FPGA knowledge (by luck!), but that might change if I move on elsewhere.

Sure, set a flag when your state machine gets to a certain state.  I wouldn't bet on finding any help whatsoever on debugging.  I could be very wrong but I have always considered this as a black art.  Forums may help but I haven't seen anything in a textbook.  But forums are somewhat limited because of the complexity of the question.  Nobody is going to paw through thousands of lines of code looking for a problem and if you narrow it down to 10 lines, you can find it yourself.  Anyway, ask away!  There are a few fellows around here who really know this stuff - I am not one of them!

>For the LC-3 project, there are less than 64 states and I would be working on only a small subset (one instruction) so debugging with LEDs and 7-Segment Displays is easy.  Even when I did a much larger project with the help of an external logic analyzer, I partitioned the problem in such a way that a single 32 channel Logic Analyzer was adequate.  I wouldn't want a LA with much less than 32 channels and it would absolutely need a state clock input.
Hmm, I can't visualize exactly what you mean here. Is this because you were working with 32 bit wide data paths? I expect to be with 8 bit wide ones for a while yet, does that mean I shouldn't bother with a LA with only 8 channels because I won't really need it for the simpler experiments, and when I get to the point I need it I should get a 32 channel one?

When I built up my emulation of an IBM1130 (the very first computer I used back in '70) I had the CPU, card reader, printer, disk, plotter, typewriter and keyboard as separate entities that all communicated to memory via DMA and some control signals.

So, in each device, I defined a 32 bit debug bus that could carry up to the top level where it would connect to the 50 pin header.  I would just comment out all but one device such that only one device actually drove the bus.  I probably could have used a 32 bit MUX with 8 inputs but it didn't occur to me.

The problem is, difficulties in code will almost never be at the top level and the only way for a lower level to get to pins is by passing through the top level.

I was using a Spartan 3 Starter Board (1200 LE version) and another identical board for the logic analyzer (www.sump.org).

Total side issue:  When designing a state machine, you have options about how the state is encoded.  It can be a integer like 13 or it can be 'one-hot'.  There are other options as well.

One-hot is usually the default because a single bit in the state variable defines the current state so no subsequent logic is required to decode state in logic equations.  However, the state variable gets to be quite wide - my IBM1130 has something like 100 states so the state variable is 100 bits wide.  This gets in the way of debugging over a 32 bit bus.  It is absolutely required that I add  debug flags inside the state code.

The LC3 project, as I built it, uses integers 0..63 for state so 6 bits carries the state.  It's pretty easy to add debug logic that kicks in at state=17.  I used integers to match the project documentation.  With 6 bit state, you can add your debug logic outside the state machine.  With 100 bit state, I had to add the flags inside the state machine.  Both schemes work and the choice isn't really academic.  I would want to avoid decoding a 100 bit variable at every opportunity.

[dmills]

Chipscope (The Vivado logic analyser) is way cool as long as you have a big enough part to accommodate both your design and enough ram to hold the captured data and as long as you don't mind a rebuild every time you want to change the trigger conditions....

However the real art of HDL design is in learning to write test benches that can verify your designs in simulation to minimise the need for messing with chipscope, HDL is actually all about the simulator and learning to make the simulation match the hardware (And the places where it can deviate), you will write far more code for test beches then you will for actual synthesis (In a sense the EE crowd invented TDD years before the software guys).

Regards, Dan.

[rstofer]

Chipscope (The Vivado logic analyser) is way cool as long as you have a big enough part to accommodate both your design and enough ram to hold the captured data and as long as you don't mind a rebuild every time you want to change the trigger conditions....

However the real art of HDL design is in learning to write test benches that can verify your designs in simulation to minimise the need for messing with chipscope, HDL is actually all about the simulator and learning to make the simulation match the hardware (And the places where it can deviate), you will write far more code for test beches then you will for actual synthesis (In a sense the EE crowd invented TDD years before the software guys).

Regards, Dan.

It is certainly my failing but I have never used a simulator.  I can see where they would be helpful on small blocks of logic but I'm not convinced they are useful on a complete system.  I certainly don't want to write a test bench to figure out why the OS isn't booting after a couple of million cycles.

The ILA is a little more useful because I can come up with a trigger in the neighborhood but, even then, when the system involves hundreds of signals, I'm just not sure what to do with that much information.  I don't know the answer but I wonder if test benches are intended to test complete systems - something with 10,000 lines of VHDL.

It's clear I don't have printf(), my preferred technique, so I have to do something else.  A logic analyzer is part of the solution but, for my projects, the BlockRAM is already being used.  ILA isn't the first attempt to internalize a logic analyzer.  There's no reason the sump.org LA can't be internalized if sufficient BlockRAM exists.  Oh, and Digilent no longer uses wide headers.  Everything is PMOD.  That classic Spartan 3 Starter Board had 3 50-pin headers.  One for the logic analyzer, one for RAM and one for the Compact Flash.  I love it when a plan comes together.  It also had PS/2, VGA and RS-232.

Some time back I was building up a PDP/11 ALU and I needed a way to test the logic.  I put together some serial registers to shift in the arguments and another register to shift out the results.  Like SPI on steroids.  In fact, it was a lot like SPI.  I used an Analog Devices Blackfin (before the Raspberry PI came along) with uCLinux to connect to an NFS server to grab the test vectors and a serializer to deal with the FPGA ALU.  It seems convoluted but it worked very well.  JTAG works a lot like this.

This whole debugging thing can be done in a  lot of ways.  Searching through megabytes of logic analyzer results isn't one of them.

In the beginning (for me) back 15 years or so, Chipscope wasn't a freebie and even if I were interested in the  simulator, I couldn't afford it.  Lately, Xilinx has seen fit to include simulation in both Vivado and ISE without charge.  Maybe if I were starting out today I would play with this.

Designing for debugging is important.

[llaith]

Quote from: rstofer on Today at 03:48:49 am

In terms of FPGA projects, I think you are underestimating the difficulty in debugging logic inside a chip running at 50 or 100 MHz (or even higher).  For the way I debug, I want to bring out certain values.  I might want the PC, Acc, Flags, ginned up debugging signals, and so on.  On my IBM1130 project, I built an external board with 4 banks of 4 digit 7-Segment displays plus I used every LED and switch on the board itself.  Then I added a 32 bit port for the logic analyzer.
Since the system had 16 console entry switches, I also implemented a hardware breakpoint.  This was invaluable!  It's real easy to talk about building up an emulation but it's orders of magnitude more complex when you have to run the factory software, unchanged.  Why isn't the system booting?  This is not a trivial question when you have to paw through both hardware and 50 year old OS assembly language source code to find the answer.
For the LC3 project I created an 8 input MUX to send values to the displays and used 3 switches to select the variable:  Debug Out (some random logic I wanted to see), PC, MAR, MDR, InterruptPriority, PSR, Register Load Signals, Addr2muxOutput and PCadderOutput.  In addition, I used all 16 LEDs, all 16 Switches an the 5 buttons.  There are NEVER too many gadgets when it comes time to debug.
A single step clock is always useful.

Oh right! I see what you mean now. Yeah, I once wrote a missile command clone (the first computer game I played) and discovered the joys of debugging game AI at 30fps! I was not prepared as stepping through the code was completely impossible. I see what you mean now. Thanks, forewarned is forearmed! As I go through the simple cases I will write the test harnesses alongside, even for my first simple projects.

When I built up my emulation of an IBM1130 (the very first computer I used back in '70) I had the CPU, card reader, printer, disk, plotter, typewriter and keyboard as separate entities that all communicated to memory via DMA and some control signals.

So, in each device, I defined a 32 bit debug bus that could carry up to the top level where it would connect to the 50 pin header.  I would just comment out all but one device such that only one device actually drove the bus.  I probably could have used a 32 bit MUX with 8 inputs but it didn't occur to me.

The problem is, difficulties in code will almost never be at the top level and the only way for a lower level to get to pins is by passing through the top level.

Excellent, I get you now, invaluable advice. Makes total sense!

Total side issue:  When designing a state machine, you have options about how the state is encoded.  It can be a integer like 13 or it can be 'one-hot'.  There are other options as well.

One-hot is usually the default because a single bit in the state variable defines the current state so no subsequent logic is required to decode state in logic equations.  However, the state variable gets to be quite wide - my IBM1130 has something like 100 states so the state variable is 100 bits wide.  This gets in the way of debugging over a 32 bit bus.  It is absolutely required that I add  debug flags inside the state code.

The LC3 project, as I built it, uses integers 0..63 for state so 6 bits carries the state.  It's pretty easy to add debug logic that kicks in at state=17.  I used integers to match the project documentation.  With 6 bit state, you can add your debug logic outside the state machine.  With 100 bit state, I had to add the flags inside the state machine.  Both schemes work and the choice isn't really academic.  I would want to avoid decoding a 100 bit variable at every opportunity.

Interesting... very interesting indeed! I can see I am going to enjoy this, these are really fascinating topics!

Thanks for sharing your thoughts

[llaith]

However the real art of HDL design is in learning to write test benches that can verify your designs in simulation to minimise the need for messing with chipscope, HDL is actually all about the simulator and learning to make the simulation match the hardware (And the places where it can deviate), you will write far more code for test beches then you will for actual synthesis (In a sense the EE crowd invented TDD years before the software guys).

Haha, TDD, I bet you guys did! When I started my career, pre-web, software was still something that went along with something electronic, so the principles of good engineering were drummed into us, and I retain them to this day. I'm quite a stickler for well engineered and well tested code, something I got from the hardware guys in my formative years!

I'll bear in mind, don't skip the simulator. To be honest, I was kinda thinking to minimise the simulator as the whole point of me going from software to hardware is to get into the real world, but I see what you mean... the first few times I want to bang my head on the wall I'd regret skipping developing expertise in the simulation side.

I'll not allow myself to be tempted to skip over it, thanks!

[dmills]

When a 'compile cycle' on a prototype PCA takes 6 weeks and costs £2,000 you swiftly start to see the problems with devops style release processes and 'agile'....

The simulator is your friend, but you need to be aware that things like incorrect sensitivity lists will cause the sim to deviate from the hardware (The synthesiser ignores them, while the simulations need them), also look into things like how simulation delta cycles operate, writing correct test benches becomes MUCH easier once you understand that stuff.

One thing you will probably discover is that your essentially sequential mental model that most software folks have is a very poor guide to writing HDL, a 'for' loop for example is fully unrolled and all the iterations evaluate in parallel.... It can be quite an expensive thing in terms of area sometimes. Always remember that you are describing hardware not control flow, it is a surprisingly different mindset sometimes.

Regards, Dan.

[rstofer]

When a 'compile cycle' on a prototype PCA takes 6 weeks and costs £2,000 you swiftly start to see the problems with devops style release processes and 'agile'....

The time lag has more of an impact on business since it extends 'time to market' and time is everything!  Late and great is still late!

Always remember that you are describing hardware not control flow, it is a surprisingly different mindset sometimes.

This is the hard part to wrap your head around until you have written a reasonably sizable project where modules interact in some way.  Keeping track of what is going to happen on the next clock edge is the name of the game.

That's one of the reasons I like the LC3 project.  It is a fairly simple CPU with a limited number of states and a bunch of little clocked processes registering results on demand from the state machine.  It is made easier by the amount of information on the Internet and the 'worksheet' provided for creating microcode - if one is going to use that approach.  I didn't but it is totally workable.

Like all things 'computer' first we do a "Hello World!" (a blinking LED in FPGA projects) and then we build a CPU.  There isn't much in the middle...

Separate topic:

hamster_nz is a frequent contributor over in the Microcontrollers and FPGA forum.  His work is excellent and there is a lot to learn from his projects:

http://hamsterworks.co.nz/mediawiki/index.php/FPGA_Projects

VHDL done right!

[rstofer]

I'll bear in mind, don't skip the simulator. To be honest, I was kinda thinking to minimise the simulator as the whole point of me going from software to hardware is to get into the real world, but I see what you mean... the first few times I want to bang my head on the wall I'd regret skipping developing expertise in the simulation side.

I'll not allow myself to be tempted to skip over it, thanks!

There's a quote from the movie "Ronin"  (Robert DeNiro) :  "The only thing is that the map, the map is not the territory."

Similarly, the simulation is not the hardware.  When designing the hardware, you need to anticipate debugging at a hardware level.

[Bassman59]

Chipscope (The Vivado logic analyser) is way cool as long as you have a big enough part to accommodate both your design and enough ram to hold the captured data and as long as you don't mind a rebuild every time you want to change the trigger conditions....

However the real art of HDL design is in learning to write test benches that can verify your designs in simulation to minimise the need for messing with chipscope, HDL is actually all about the simulator and learning to make the simulation match the hardware (And the places where it can deviate), you will write far more code for test beches then you will for actual synthesis (In a sense the EE crowd invented TDD years before the software guys).

This is the truth!

And every time I go to make a change and say to myself, "nah, I don't need to re-run the test bench," the thing doesn't work and I re-run the test bench and see the problem straight away.

Every single time.

[llaith]

Like all things 'computer' first we do a "Hello World!" (a blinking LED in FPGA projects) and then we build a CPU.  There isn't much in the middle...

Haha, I'm so totally guilty of exactly the same thing, played with my arduino a bit, discovered FPGA's, decided I should create a CPU cause I always wondered 'how they worked'

To be fair though, I was inspired by a dramatisation on the BBC about the Sinclair vs Acorn era https://en.wikipedia.org/wiki/Micro_Men (I was sent to a 'computer camp' in the hols before high school started, with the ZX-81 and Spectrum). From that drama, I became a fan of the real world Prof. Steve Furber (https://en.wikipedia.org/wiki/Steve_Furber) and Sophie Wilson (https://en.wikipedia.org/wiki/Sophie_Wilson). Although I am following Steve's amazing work with the Human Brain Project, Sophie is also an incredibly inspiring and humble person, and I was blown away by this talk given to an audience of fellow Erlangers: , which offered a a truly fascinating perspective on the industry. I'm pretty sure she's spot on, it will be machine learning algorithms in FPGA's that will power the future of computing via massive parallelisation.

hamster_nz is a frequent contributor over in the Microcontrollers and FPGA forum.  His work is excellent and there is a lot to learn from his projects:

http://hamsterworks.co.nz/mediawiki/index.php/FPGA_Projects

VHDL done right!

Excellent link, thanks! Nicely documented VHDL also, very cool. Ta!

[rstofer]

A very interesting talk!

[haastyle]

Hi there,
My Haasoscope might fit your needs. It now has a logic analyzer as well as 4 channels of adc, for just $100.
https://www.ebay.com/sch/i.html?_nkw=haasoscope