| Electronics > Beginners |
| modern TTL/Logic-gate/74xx |
| << < (5/13) > >> |
| ker2x:
I'll address this whole FPGA issue : I could do it if i really wanted to and *had* to do it. I write fortran (and other languages) as a hobby. I write SQL as part of my job. I obviously can do ASM too. (since i'm designing a cpu and emulator in software). I could do VHDL/Verilog. i just don't want to, don't wanna, nope, no way, eww, poop. Doing it with an FPGA would be like writing a emulator in a language i hate. And i'm already busy writing one in a language i love. :-// And how am i supposed to fail in electronic if all i have to do is to buy an FPGA dev board and write code ? It's not 100% out of the way. I may end up using one despite my best effort to avoid it. But if i do : - it will be for the non-cpu part of the computer - it will be because using a microcontroller for the non-cpu part of the computer didn't work the way i expected for unforeseeable reasons. - it will be because i couldn't test a submodule of the cpu with the microcontroller. - it will be because i want to. As of today : i don't. I will take a look at (C)PLD however, because i apparently misunderstood what it was. Later, because i just watched the clock and i was supposed to be at work 12mn ago. oops. :rant: |
| hamster_nz:
The agile snark was a bit of a joke... Everything is going 'agile' . But it could actually be possible to do, as you will have quite a few mundane tasks that could be automated along the way from design to hardware. |
| rstofer:
There's another way to architect an FPGA CPU that is almost never seen in the wild: Build up a library of 74xx(x) blocks. Then 'wire' the blocks together just like you would do it on a wire-wrap board. Build modules for 7400, 7402, 7404, 7408, 7474, 74181, 74182 and all the others that come up. This is a terrific way to use logic chips as the design elements rather than more conventional FSAs and the other constructs. It would be a very interesting design! Elegant and unique! You can design the 74181 block in behavioral code (specify the inputs, outputs and function) or model it with lower level logic chips from the datasheet block diagram. I might do that in a later pass but behavioral code would be my first choice. But it would be as simple as substituting one file for another and recompiling to change to the more detailed design. I would still lay out a microcode word and use microcode for the control unit. Among other things, the typical large FSA isn't needed and although we know that, in the end, the FSA will look a lot like a microcoded solution, one big difference is that the FSA will probably use 'one-hot' encoding so an FSA with 100 states will have a 'state' and 'next_state' vector width of 100 bits. We don't want that for our microcode word width so many fields will be encoded like MUX select bits. Three bits select 1 of 8 mutually exclusive values rather than having 8 signals going to AND gates. In real hardware, it is common to use tri-state bus drivers to send signals from registers to some bus. This doesn't tend to work very well for FPGAs so we have to implement MUXes. Turns out the synthesis tool will do that by magic if you try to define tri-state drivers. Everything that needs to happen and the sequence of events is contained in microcode. Not too many people remember but IBM invented the 8" floppy. Why? To load the microcode for the IBM360. https://en.wikipedia.org/wiki/History_of_the_floppy_disk For the meta-assembler, and you would probably need one, you define a word width. Then you define 'fields' within the word (or define the word as a collection of fields). Perhaps 3 bits are allocated to the selection input to an 8 input MUX, something like that. Further, you define default values for each field so that each line of microcode doesn't have to define every field, many of which are not involved with the current operation. Each line of 'code' defines values for the fields at a particular memory location in the microcode. Extra credit for macros. Maybe use the C preprocessor? There's a simple Python program in here, screaming to get out! But, really, it simply MUST be written in Fortran. Characters and strings are such a PITA for Fortran! We had to rewrite IBM's Commercial Subroutine Package for the IBM1130 to get some speed out of business applications, circa 1970, and the main thrust was string manipulation. In the end, you wind up defining every bit in every word in the microcode store. Now, the microcode wants to be alterable and not totally compiled in to the VHDL. Hit up hamster_nz for his code on reading BlockRAM values from a hex file during the Implementation phase rather than way back at Synthesis. I don't recall where I found it but I used it for my LC-3 project. Extra credit if you use an SD card to hold the microcode and can come up with a simple way to read the file during boot. Heck, IBM did it way back in the late '60s. ETA: Once you have the FPGA version working, it would be pretty trivial to use the same blocks to design/build real hardware. Think of the FPGA as a high end simulation. |
| rstofer:
--- Quote from: ker2x on October 08, 2019, 06:41:40 am ---And how am i supposed to fail in electronic if all i have to do is to buy an FPGA dev board and write code ? --- End quote --- It is common for programmers of procedural code to look at Verilog and VHDL as just another language. It is, and it isn't. Yes, they are both languages but... They're describing hardware, massively parallel hardware! Eventually the programmers come to realize that every single line of code in a 10,000 line project is executing in parallel. Signals 3 levels deeper are still changing state, massive things are happening on each clock pulse. Just handing data off from one module to another has timing implications if the processes are clocked (one clock delay is typical, sometimes 2 if crossing a clock domain). It is up to the designer to keep track of the timing of every signal in the design. In bits and pieces, true, but everything is happening in parallel. There is nothing in the world of procedural code that comes anywhere near to being as massively parallel as writing in an HDL. What ? A CPU has 4 cores and 2 threads per core? 8 things going on at a time? That's trivial! In HDL I can have thousands of independent processes all running in parallel, happily moving information from place to place. Got FreeRTOS running? Great! But it's still just serializing. Hardware design is the ultimate game! But sometimes it just isn't practical to build things with discrete chips. My personal limit for wire-wrapping is about 100 chips, a very modest CPU depending on how the registers are implemented. That's a LOT of chips but beyond that point my attention span falters. My scratched out logic designs just aren't formal enough. Documentation becomes more important than wire-wrap and it becomes more work than play. |
| ker2x:
FPGA again ? ... ok, ok. you guys win, i'll consider it. :-// And i kinda like the idea of implementing the whole serie of 74xx, just for the fun of it. Even if i'm not really sure if it make sense, but common sense doesn't matter in this kind of project ^-^ I think i need a drink. cheers ! :popcorn: |
| Navigation |
| Message Index |
| Next page |
| Previous page |