• Content Count

  • Joined

  • Last visited

Everything posted by CurtP

  1. Very good to know! I feel like there are a million little things I don't know about VHDL, and the worst part is that I don't know what I don't know, haha.
  2. tempResult is a 33-bit variable, used for convenience within the process. Its use is appropriately expanded upon elaboration and synthesis. It isn't used to register a value between cycles. The result signal becomes tempResult(31 downto 0) and the carry flag bit on the flag signal output becomes tempResult(32). Using a simple container module for clocking and I/O, I have synthesized and verified its operation on a Spartan7 board.
  3. I view signed and unsigned as just different ways to look at a bucket of bits. My current practice is to favor the use of std_logic_vector for moving and storing data, and converting to unsigned for arithmetic and logical operations. I try to minimize the use of casting or conversion to types that don't preserve 9-level logic, as this can hide problems in simulation that might pop up in implementation. So if I need to perform arithmetic on a set of std_logic_vectors, I convert them to unsigned, perform the operation, and then store the results as std_logic_vectors. Wherever possible, I tr
  4. I'm going to heed the advice of pretty much everyone on this thread and tackle some more simple, self-contained projects to better learn the craft, and the quirks. It is important to understand the basic platform you're working on before developing something highly advanced on it. As for the advanced features and optimizations you mentioned, you're probably right to say that implementing them will be difficult, time-consuming and possibly not even necessary. But those very aspects are essentially the reason I'm doing this. The genesis of my fascination with CPU design comes from when I wa
  5. Only experience can teach what this truly is like, but I can say that this is pretty much what I was expecting. The people who succeed the most often fail the most, because they actually tried. Success is primarily a function of recovery from failure. But at least I have the benefit of being on my own timeline and own (non-)budget. Just me, my free time, an Arty S7, and my sanity (for now). That said, the prevailing advice seems to be to build smaller projects first. I initially had figured "well, the smaller functional units -are- smaller projects". But I can see why it would be advantag
  6. I get where you're coming from. If one isn't careful, they can extinguish their own enthusiasm for something by taking on way too big of a task, way too early. @[email protected] has strongly suggested that I build the peripherals for my CPU before building my CPU. This is probably the course of action I'll ultimately take (maybe building small parts of the CPU along the way). This approach could kill two birds with one stone: setting me up with a proper debug environment, and giving me some more simple projects to work on first.
  7. Thanks for getting back to me! Are there any specific pros/cons to registering the outputs of the register file that I should be aware of? This design is specifically targeted for use in a bespoke CPU design, not as a general purpose module to be re-purposed by others. So in the context of my own design, what should I worry about? All module outputs are sampled at the rising edge of the clock. Would leaving the outputs unregistered put my design at risk of sampling spurious/undefined values from the register file based on factors like clock skew or others? And thanks for the clarific
  8. This gives me a few things to think about. One of the most difficult tasks is discerning the base level functionality you have to provide for an OS and a software toolchain to function. For example, I do want to implement an MMU with some manner of paging mechanism, as well as user/supervisor execution mode (which will of course require the paging mechanism to check page descriptors for security-related attributes). As for unaligned accesses, the whole topic sounds messy and like it'd add a lot of complexity (and latency). I would like to avoid implementing it if possible. If there is a s
  9. Hi Dan! Glad to meet you. I had already heard about the ZipCPU prior -- it's great to find the maker right here on the forum! Thanks for your insights and resources. It helps to hear from someone who has already gone through the CPU development process. You've certainly given me a lot to pour over! Especially helpful at this stage is your information about pipelining strategies. From my perspective, one of the most intellectually challenging tasks of the entire design is figuring out how to get the right data at the right stages of the pipeline at the right time, while minimizing sta
  10. Thank you for the kind words and encouragement! The first big project I'm working on is.. (wait for it).. a general purpose CPU. Cliche, yes, I know. But I see it as a labor of love, an opportunity to learn many principles of machine design at once, and just something I've been really curious to do for a long time. I'm sure the world doesn't need yet another new ISA, but it's still fun to create one. And I'll be open-sourcing the final product, for whoever might find it useful. One of my design goals (or I suppose you could call it a meta-design goal) is to prioritize the use of e
  11. I have found the schematic views of elaboration/synthesis/implementation to be very helpful for improving my understanding of VHDL and my target FPGA. It's one thing to see simulation results on a scope, but it's another to see the actual hardware that the tools generate from your VHDL. I try to ask myself as I go "what hardware will this create?", and am picking up best practices bit by bit. For every functional unit of a design that I create, I make sure to walk through the elaborated schematic and understand what each part is doing. I find that making small changes to the VHDL and seeing ho
  12. Thanks for the advice! My journey into hardware design has been like drinking from a firehose of information so far, but that's part of the fun. You're correct that being accustomed to software development paradigms can be an impediment to learning hardware design. I think a lot of people see the superficial similarity between HDLs and C-style languages and assume that the process will be similar. It has been an interesting exercise to rework my thinking around describing the behavior of a circuit, rather than listing a series of concurrent operations to be performed. I think one advantag
  13. Thanks for the explanation!
  14. Thanks for all the info! My background is software, primarily C/C++, so I am still learning the stylistic conventions of VHDL and HDLs in general as I go. It helps to have other engineers point me in the right direction. A few questions, if you don't mind: When you say "infrastructure", are you referring to things like clock, reset, and other signals that propagate broadly through the design? Regarding distributed memory versus registers -- you're correct that this design infers registers upon elaboration. What kinds of tradeoffs are involved in choosing which design to pursue?
  15. Hey everyone, I've done the initial design of a register file (16x 32-bit registers, two write ports, four read ports) in VHDL as part of a larger project, but seeing as I am a relative newcomer to HDLs, I was hoping to get some feedback on my design, any errors I may have made, or any improvements I might want to make. Here is the VHDL: -- Register file -- Two write ports, four read ports. -- For performance reasons, this register file does not check for the same -- register being written on both write ports in the same cycle. CPU control -- circuitry is responsible for preven
  16. Hey everyone! I registered here a while back but never got around to posting an introductory thread. I was happy to find such a large community surrounding Digilent boards and FPGA development in general. I'm a newbie to HDLs and the process of hardware development in general, but I can say that I've spent at least a decent amount of time studying the theoretical principles of computing and machine design. I have a background in computer programming, and it's been very interesting learning the many differences in methodology between programming and hardware description. I know i
  17. UPDATE: I figured it out. An error I made deeper in the design led to the output signal effectively never being set to any value except "0000", hence the trimming of logic. Thanks for your time! Curt
  18. Hey everyone! I'm new to the forum (and fairly new to VHDL as well), and I was hoping you could help me with a problem. I have a project that I'm working on in Vivado (currently it's just some of the inner-workings of a CPU in development), and I'm trying to implement a container that helps me test the design on my FPGA board (Spartan 7 on a Digilent Arty-S7). The top-level module routes the clock input and reset button input on the FPGA in to the design (inverting the reset button input from active-low to active-high in the process), and routes a 4-bit vector out from the design to