| Electronics > Beginners |
| Yet another question on scopes :) |
| (1/4) > >> |
| 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:
--- Quote from: llaith on October 04, 2018, 04:44:58 pm --- > 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. --- End quote --- 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. --- Quote --- >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... --- End quote --- 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. --- Quote --- >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. --- End quote --- 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! --- Quote --->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? --- End quote --- 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. |
| Navigation |
| Message Index |
| Next page |