#cpld

XCZU9EG-2FFVB1156E AMD ( XILINX FPGA/CPLD) FCBGA-1156(35x35) XC7S6-1FTGB196I AMD ( XILINX FPGA/CPLD) CSBGA-196(15x15) XC9536XL-10VQG44C AMD ( XILINX FPGA/CPLD) VQFP-44 XC7S50-1CSGA324C AMD ( XILINX FPGA/CPLD) CSGA-324(15x15) XC3S1000-4FG320C AMD ( XILINX FPGA/CPLD) FBGA-320(19x19) XC2VP7-6FG456I AMD ( XILINX FPGA/CPLD) XC2S200E-6FTG256I AMD ( XILINX FPGA/CPLD) XC2S50E-6PQ208I AMD ( XILINX FPGA/CPLD) XC2S150E-6FTG256C AMD ( XILINX FPGA/CPLD) - XC6SLX100-3FG676I AMD ( XILINX FPGA/CPLD) FCBGA-676(27x27) XC5VFX100T-2FF1136I AMD ( XILINX FPGA/CPLD) XC4085XLA-09HQ240C AMD ( XILINX FPGA/CPLD) XC95108-10PQG160C AMD ( XILINX FPGA/CPLD) XC6VLX240T-2FF784I AMD ( XILINX FPGA/CPLD) XC7A25T-1CPG238C AMD ( XILINX FPGA/CPLD) CSBGA-238(10x10) XCR3512XL-10PQ208C AMD ( XILINX FPGA/CPLD) XC9536XL-10PC44I AMD ( XILINX FPGA/CPLD) 44-LCC（J 形引线） XC9536XL-7VQ44C AMD ( XILINX FPGA/CPLD) VQFP-44(10x10) XCV300E-7BG432I AMD ( XILINX FPGA/CPLD) 432-LBGA XCZU4EG-1SFVC784E AMD ( XILINX FPGA/CPLD) FCBGA-784(23x23) XCF16PVOG48 AMD ( XILINX FPGA/CPLD) XC95288XL-7FGG256I AMD ( XILINX FPGA/CPLD) FBGA-256(17x17) XC95288XL-10TQG144 AMD ( XILINX FPGA/CPLD) XCKU040-3FBVA900E AMD ( XILINX FPGA/CPLD) XC3S1600E AMD ( XILINX FPGA/CPLD) XC18V04 AMD ( XILINX FPGA/CPLD) XC7A15T-1CSG325 AMD ( XILINX FPGA/CPLD) XC7A100T-1FGG484 AMD ( XILINX FPGA/CPLD) XC7K160T-FFG676 AMD ( XILINX FPGA/CPLD)

No general-purpose computer will do much without a good amount of Random Access Memory for transient storage of code and data. Now that I have confirmed basic operation of CPU, bus controller, ROM, and serial, it's time to turn my attention to main system memory.

Every homebrew computer I've built to date, including previous iterations of the Wrap030 project, has used Static RAM. Static RAM is nearly as simple as peripherals can be — give it an address, assert a Chip Enable and a Read or Write strobe signal, wait a bit, and release. Done, cycle complete. If you don't need to retrieve some data for a good long while, it's no matter so long as the chip still has power. For a small system, SRAM is reliable and dead simple to use.

The problem with SRAM is it is also very expensive. The 2MB of SRAM I had on the previous iteration of Wrap030 cost over $20 — and it's still far from enough to run an operating system like Unix System V, NetBSD, Linux, etc. This is the reason computers generally use Dynamic RAM for primary system memory.

The difference is SRAM uses several transistors to create a flip-flop for storing each and every bit of memory, whereas DRAM uses a capacitor to store each bit of memory. This reduces manufacturing costs and increases storage density, but does come with some trade-offs. Most notably, the capacitors that store bits in DRAM will lose their charge — and the stored data with it — after a rather brief period of time. This means the DRAM capacitors need to be topped off regularly in a process known as a refresh cycle.

Another complication of using DRAM is the bus interface has been changed to allow much larger storage capacities without the physical chip package growing to absurd sizes. Instead of the chip accepting the entire address at once, it expects to be given a Row address (along with a Row Address Strobe [RAS#]) then a Column address (along with a Column Address Strobe [CAS#]), with myriad specific timing requirements for when each signal should be asserted and deasserted.

In short, DRAM is much more difficult to interface with compared to SRAM, so I've never really gotten around to it.

With one of the long term goals of this project being running a *nix operating system though, I'm going to need the larger memory that DRAM affords. So i made provision for a CPLD to serve as a dedicated DRAM controller on the Wrap030-ATX motherboard and added a couple 72-pin SIMM slots. In theory this setup should be able to support up to 256MB of RAM (if rare 128MB SIMMs should fall into my hands...).

So where do we turn when dealing with complicated timing with multiple modes and a bunch of I/O? Why, Finite State Machines, of course! That bit where the DRAM expects a row address for a little while, that's a state. And the following bit where the DRAM expects a column address is another state. And then another state to make sure the DRAM has enough time to write or fetch the data. The round it out with one last state to tell the CPU data is ready.

What about that weird refresh timing? Well, that's just few more states for the state machine. And then one last "idle" state that waits for a refresh timing counter to hit 0 or for the CPU to start a bus cycle. Laid out like that, the DRAM controller became a state machine with 7 or 8 states, a counter, and an address multiplexer.

The logic actually came together easier than expected. Not completely without bugs of course.

There's this note in the datasheets about startup initialization where the DRAM should not be accessed 200μs after power on, and there should be 8 refresh cycles before the first access. Initially I had built this entire sequence into my logic. It consumed a ton of resources and didn't really work right.

I realized that my reset circuit held the CPU in reset for longer than 200μs on power on, so I was guaranteed that first initialization time. So I removed that startup delay from my DRAM controller logic, and made a few tweaks to the state machine so it could do 8 back-to-back refresh cycles after reset.

I was able to successfully write to DRAM and read that data back!

That much proved to be the easy part. The next steps were confirming DRAM accesses worked reliably, that I had the order of my byte select signals correct, that I could identify the amount of installed memory, and that all of the installed memory was working. These are programming problems, not logic problems, and I am not a strong programmer. On top of that, not only am I working with unproven DRAM logic, but I'm also using untested SIMMs that I had picked up from Computer Reset.

I quickly ran into errors, but was it a problem with my logic? A problem with my timing? A problem with the SIMMs?

I had a large back of 72-pin SIMMs, split fairly evenly between Fast Page Mode (FPM) and Extended Data Output (EDO) types. I tried them all. Some would pass the tests for nearly all addresses but fail at the end. Some seemed to have a stuck bit. Some were just plain bad and gave errors everywhere. It didn't really answer the question about whether my logic was bad, but results were consistent enough for me to think that maybe the logic might be ok.

And then finally I came across a pair of HP-branded 8MB EDO SIMMs that passed a simple write-read test without error ...

... right around the time my serial port stopped working. But the memory test was passing, and I could at least see the serial output on the logic analyzer.

The serial port problem was a bit setback. It had been working but suddenly wasn't. Clearly the UART itself was working, I just wasn't getting anything past the level shifter. Well that at least gave me a starting point of where to look. Sure enough, one of the 12V supply pins was not well soldered. Thankfully a quick fix.

Back to testing memory, I started writing a program to identify the size of the installed SIMM and write a register I added to the DRAM controller to configure the specific geometry of the installed memory. See, DRAM has another lovely quirk — chips of the same size may have a different configuration of Row and Column sizes. For instance one chip may have a 9-bit Column and a 10-bit Row, but the next may have a 10-bit Column and a 9-bit Row, and both are the same size. If the DRAM controller just assumes 12-bit Row and Column (the largest supported by 72-pin SIMMs), then there will be gaps in the memory map that will need to be accounted for in software (using MMU, for example). If the DRAM controller knows the geometry of the installed memory, then it can present the memory to the CPU as one contiguous block of memory.

And that's where I found my next bug. The system would just hang when trying to write to that DRAM controller configuration register.

... because I had forgotten to complete that part of the state machine. The result was the state machine would end up in a state for writing to the configuration register, but then it couldn't get out of it. Once I added the missing condition to the state machine logic I was able to correctly identify the geometry and size for my installed memory!

Wow that was long. This has been the biggest, most involved step in the process of bringing up this computer yet. It turns out there are a lot of moving pieces that have to all work together to get the computer running code from ROM and reading/writing DRAM.

Zolatron 64: adding a memory expansion board #6502 #homebrew computer

Things are continuing apace with the Zolatron 64 6502 homebrew computer. In fact, progress has been so rapid that I haven’t really had much time to talk about it. So here’s a quick refresher – and details of the new memory expansion board. Serial killer The 6551 ACIA serial board is dead. Well, it’s not dead, but I’ve stopped using it. As I mentioned in the last update, I now have another serial…

This is a big step forward — Wrap030-ATX, my microATX form factor 68030-based homebrew computer, is running code from ROM. Externally, all it's doing is blinking an LED, but that LED is software-controlled, with a sizable delay loop between blinks to make it something that is human-visible.

Getting to this point took quite a bit of work after the free run tests. Nearly all of the logic on this project is in CPLDs. Of note here is the primary bus controller, which handles access timing, bus cycle termination, and a settings register.

For the computer to run code, it has to be able to read from ROM. Reading from ROM requires the bus controller to decode the CPU address, assert the ROM's Chip Enable (CE#) and Output Enable (OE#) signals, wait the appropriate length of time for the ROM to output stable data on the bus, and then assert the appropriate bus cycle termination signal for an 8-bit peripheral (DSACK0#).

Once I had the minimal functionality for ROM access cycles, I was able to repeat the free run test, but this time with only the to 8 bits of the data bus (D[31:24]) pulled low.

Once I confirmed the ROM access cycle logic was working, I added the bus controller register access cycle logic. The bus controller has a single settings register that will control the Debug LED, startup ROM overlay, and ATX soft power. The CPU will need to be able to write to this register, and reading from it is helpful as well.

The bus controller logic is fully synchronous and managed by a state machine, so all that was needed to add the settings register was a couple new states for the state machine — one for read and one for write.

Put all that together, and we have a computer that can run the most basic of programs, with just a single LED for output.

Intel Altera FPGA chips from the original factory have a full-line price increase, with the highest price increase of 20%. The price increase notice is as follows.

101 lnnovation DrSan Jose,CA95134 altera.

An intel Company October 23,2024 Dear Customer, Altera remains focused on delivering a broad portfolio of FPGAproducts that satisfy a diverse set ofapplications while providing stable long-term supply.Due to market pressure and increased operatingcosts,we are raising prices on several Altera product families.These price adjustments are required tomeet our commitments and goals to our customers regarding long-term longevity and maintain stablesupply in our business to deliver a broad portfolio of leading FPGA products and solutions.

The scope of price adjustments for Altera products is as follows:

7% increase on Cyclone 10 GX/LP,CycloneV,CycloneIV,MAX@10,and MAX@ V 10% increase on Agilex'M 7,AgilexM 9Stratix10,Arria@10

20% increase on all Stratix@V,Stratix IV,Stratixlll, Arria V,Arriall,Cyclonelll,CycloneII,[email protected] EPCO-AThe price adjustment will become effective on November 24,2024,and will impact all orders,all quotes.and all shipments on and after November 242024,

If you have any questions about these price adjustments, please contact your Altera Sales Representative or Altera Authorized Distributor.

Sincerely,

Deepali Trehan

Vice President General Manager

Product Management & Marketing

A newbie's introduction to #CUPL and #CPLDs

When you’re dealing with computer logic, things can get very complicated very fast. This is especially true when it comes to address decoding. You can easily find yourself tangled in a messy web of AND, OR, NAND and NOR gates. And there’s a problem you can run into when stringing together a bunch of logic gates – propagation delay. It takes a measurable amount of time for a chip to convert input…