• Reinventing the wheel, part 2: I can't believe it's not VERILOG!

    Katherine Peeters07/03/2021 at 01:01 0 comments

    You would not believe how tired I am of writing toolsets now.

    Last episode I started expanding my in-progress "gennet" Python module into a fully fledged circuit generation and digital simulation tool. Since then, a lot has happened. Long story short, "gennet" is now in the trash bin due to concerns about efficiency and code quality, and I've instead gone the extra mile and written an entire C library from scratch.

    The new library, named libcirc, allows you to use C like a sort of high-level HDL, generating circuits which can then be validated with libcirc's built in digital logic simulator. Once you're happy with your design, libcirc allows you to export it as a KiCad netlist that you can then import into KiCad's PcbNew routing tool.

    Needless to say, this was a huge pain in the ass, but the good news is that I'm not just writing about some work-in-progress half-completed tool. It's done, libcirc is fully functional, and I have no further plans for it at the moment. So, months and months later, I'm finally getting back to work on the actual SL-16.

    What's left to do now is write the code to describe the SL-16 with my fancy new library, which hopefully shouldn't take long. With luck, I'll finally be moving on to PCB routing in the next week (or at the very least, debugging the inevitable problems with the design that the simulator is going to reveal). It's about time!

    If anyone's interested in taking a look, I'm happy to publish libcirc as an open source tool, but unless there's pressing demand or something I'm currently trying to stay focused on the meat of this project, so I don't plan on publishing the library until later.


  • Reinventing the wheel

    Katherine Peeters06/08/2021 at 14:37 0 comments

    I hate myself for doing this, but I've now expanded the "gennet" module I created for this project to not only be a netlist generator but also a digital logic simulator.

    The reasoning behind this decision is that (as others have pointed out) SPICE is not really the correct tool to be using for verifying a design like this, but at the same time, I'm unsatisfied with the available options for existing digital logic simulators. I've found them to generally either be closed source or written in a non-native programming language (eg Java, JavaScript, etc).

    So I gave up and made my own. There were a few road bumps, but the simulator is now almost in a working state, and I've finished up some other projects that were distracting me (notably LibreJam 202106), so we should be back to your regularly scheduled SL-16 development pretty soon.

    (And yes, I'm aware it's rather hypocritical of me to complain about simulators being written in non-native languages and then write mine in Python, but shush. Maybe one day I'll rewrite it in C. Maybe.)

  • Quick status on SPICE models, and why TI sucks

    Katherine Peeters05/23/2021 at 21:32 0 comments

    Hello, this is just going to be a quick log to note what I'm working on at the moment. The "gennet" module is pretty much working at this point, so the issue now is getting SPICE models for the various 74XX components the design uses. Unfortunately, this has proved difficult.

    Texas Instruments provides models for some of their components, however they provide them only for their proprietary PSPICE simulator, so their models are not compatible with ngspice or any other open source simulators. As I have been unable to find any other models available for these components, I'm left with only one option, which is to write all the models myself. Ugh.

    So yeah, this will take longer than expected. I'm new to SPICE in general, so going from nothing to writing the models for all these parts is going to take some time. Nevertheless, the project is moves forwards...

  • Software shenanigans: Rebirth of the "gennet" module

    Katherine Peeters05/17/2021 at 13:09 0 comments

    I haven't posted a log in a few days, which feels wrong given much work I've been doing on the project. Initially I didn't want to post logs just for software cleanup stuff, but in this case it's been long enough that I think it would be good to give a window into what I'm working on. For the curious, there will be a proper log entry in the next few days going into simulating the design with SPICE.

    When I started working on this revision of the project, I began writing code for generating a KiCad netlist similar to a Python module used in a Verilog synthesis tool I had previously been playing with. Originally the intent wasn't to develop a complete module for this; after all, I just wanted a solution for this single project. Nevertheless, after a few weeks of work, it's evolved into a more complete tool that could be reused in other projects. At some point I'll publish it in its own Git repository, under the name "gennet".

    The tool takes an object-oriented approach to creating netlists programmatically, and the resulting netlist object can then easily be converted into different formats, such as KiCad or SPICE. I've spent most of the past few days reworking the code to take a more modular approach (originally the code was hardcoded to generate a KiCad netlist), as well as creating a JSON file with component "templates", which provide the information needed to translate a generic netlist to a specific format.

    The KiCad formatter is now working (well, theoretically working, it hasn't been tested yet because my KiCad install is broken at the moment, but that's a different story), so I'm now working on the SPICE formatter. After reading some documentation, I have to say I was pleasantly surprised at how easy the SPICE netlist format is, so hopefully I'll get it working in the next few days. Stay tuned!

  • Initial commit (er, I mean log)

    Katherine Peeters05/12/2021 at 01:29 0 comments

    I actually started this project awhile ago, before I started using this site, so there's plenty to catch up on.

    The project has gone through three major "revisions" so far. I choose to call it a "revision" because it sounds better than "attempt". The first approach was to do everything by hand in KiCad. This technically works, but it was a huge pain, and is obviously not very flexible. My second approach was to implement the CPU in Verilog. Again, this technically worked, and this time I did get past the simulation phase, successfully verifying the design with the open source tool Icarus Verilog, however I quickly learned that synthesizing the design into 74XX parts was troublesome and very inefficient in terms of part count.

    The current attempt is a cursed hybrid of the two. Stealing some ideas from the Verilog 74XX synthesis toolchain I had been experimenting with, I began writing a Python program which outputs a netlist compatible with KiCad. However, instead of merely converting the netlist from one format to another, this new program actually generates the CPU itself. So, it's almost as if my original Verilog code was synthesized and converted by hand into Python code. Saying that out loud, it sounds like the most horrible thing I've ever done in my life.

    As janky as it is though, the Python script does work. Which brings us to the present day: The script now generates a netlist which is probably mostly connect, so the next step is to verify the design. The obvious approach would be to use SPICE, however I'm realizing a bit too late that I'll need to generate netlists in a different format to do that. Oh well; it's not that bad, it's all just abstracted Python code anyways.

    So, that's the story of where we came from, and where we're going now.

    TL;DR life is pain and the current goal is to get the design loaded up into ngspice.