Dual port BRAM. Two ports can be read in parallel. Usually they can be written one at a time.
There are special FPGAs where two ports can also be written in parallel, but this adds issues.

LOL, eBay reports this



to whom is interested in the purchase of a physical book like this: try on Bonanza first, or on Amazon second hand books, eBay is funny these days.

Amazon tends to be item $1 shipping $80 for Canada. Abes books also are nice, books a nice price and low cost shipping.
typical ($10 book $15 shipping from the US). ($5 book,$5 shipping from the UK).

Yes, we should start a resources thread. I don't even know where to begin, but probably a bunch of links to interesting datasheets on bitsavers would be a start. Good books would be great, though I didn't learn too much from books personally. Reverse engineering articles. Github repos and blog articles. I learned a ton from the magic-1 and pretty much everything Dieter writes. And of course Ben Eater whose series I link in the description of all my videos as he's the one who got me into this.

FPGA reviews and reliable sources for old chips would be good too... especially anyone that knows where there are caches of "old new stock" that aren't counterfeits or referbs.

In other news, I recorded a video on converting the hardwired logic to microcode -- I just dumped all the logic into a ROM and promptly got myself stuck for a couple days, since I had no way to generate that ROM from assembly, and when I did it was almost unreadable. I did a LOT of research trying to figure out how to get myself unstuck. But I recorded another video this morning where I (at least temporarily) restore some of the hardwired logic around conditions until I can incrementally build a proper solution for handling conditions in the microcode. That cleaned up the microcode listing considerably. And I think I have a good plan for forward progress.

Anyway, hopefully I will have time to release a video or two this weekend. I am going to edit one right now, it's about half done. Will update once I upload it.

Here is the next video. I implement conditional branches with a T bit and a branch if that bit is true and another if it's false. I also begin to separate out the control logic and start building upon that hardwired logic for the next 3 videos, after which I begin the journey to microcode. The temporary musteq instruction is also converted to a halt that can assert an error line if the T bit is false.

[022] Conditional Branches! https://youtu.be/YI-500Jc0R4

Next video will be memory access, which will make the processor Turing complete.

> I just dumped all the logic into a ROM and promptly got myself stuck for a couple days, since I had no way to generate that ROM from assembly, and when I did it was almost unreadable

This seems a nice illustration to me: to use microcode is to move complexity away from the logic implementation, and into the bits in the ROM. It doesn't, in some sense, reduce the complexity: it moves it. It does reduce the implementation complexity though, which makes it quicker to design and build the hardware, and it also serves as a form of late binding, in that you can (generally) update the ROM contents at a late stage of build, or even after the build.

PAL logic can also compliment microcode logic. For my latest design I have 3 512x8 proms and 4 22v10 pals in the control segment. The data path uses 2901 with a 22v10 pal for Excess 3 logic and BCD/binary conversion for each 4 bit slice.
Each PAL replaces about 3 to 4 TTL chips.
Microcode logic seems complex because with the advent bit slice logic,people wanted to add as many features as posiible
like floating point or bit mapped graphic operations or P-code like virtual machines. The high end machines often had writeable microcode, so you could have different decoding for the same machine, like Fortran and C.

Which machines?

It was an option for some VAX models: at my place of work (about '84) they'd cooked up some microcode to assist parallel fault simulation.

PDP 11/60 was also user microprogrammable.

The Burroughs B1700/B1800 were specifically designed as interpreting machines that were used to interpret a number of instruction sets, some of which were specifically oriented to support specific high-level languages: "Interpreting Machines: Architecture and Programming of the B1700 / B1800 Series", Elliot I. Organick and James A. Hinds.

Architecture and Programming of the B1700 / B1800 looks like a nice used book, only 4 now left in the UK after my order goes thru.
Any more must have 'computer books'? (feel free to move to a new thread).

Next video is up! The processor is Turing Complete as far as I can tell from what I have read. It has conditional jumps and sufficient amounts of memory.

I also discover that this processor is going to have challenges running in an FPGA since it can't work with synchronous memory (block RAM). But I will work towards fixing that in the next couple videos.

[023] Turing Complete with Data Memory! https://youtu.be/IPArz7inzu8

Question: should I stick with a Harvard memory architecture? Or should I try to go for Von Neumann? With Harvard, I effectively get twice the memory with 16-bit pointers. But with 32 instructions, there's no room for instructions to read/write program memory. So I would have to implement some sort of memory-mapped device to read/write program memory if I want to support a bootloader. Von Neumann would be simpler, right?

I mean, Harvard is usually chosen because it's faster, but in a multi cycle machine, I have to calculate the address in the first cycle and then do the load or store in the next, and so even if I pipeline the fetch, the memory is idle in that second cycle. Right? Block RAM should be fine with back to back reads or writes, right?

And even with Von Neumann, there's no reason I couldn't have separate address spaces for program and data still, if I have a way to specify different "pages" or "segments" or whatever for code vs data. So I think there's no advantage to Harvard, and just extra complication right?

It really depends on what you want to do.Simple 8 bits gets you a BASIC in ROM,. 16 bits is just ample to run a simple OS and have a Compiled Language and a small editor. 32 bits will give you a MSDOS like OS and 1 Meg of memory.. Any thing bigger requires sadly virtual memory. and that is a topic often skimmimed over in computer design.
16 bit Havard is better way to go, as memory could all sit in ALU logic section, and only 8 bit I/O need come out on a bus.

With a pure Harvard memory architecture basically you need two simple instructions to manage the code-space as data-space: ldcd stcd.

Avr8 and even the iJvm are two practical examples (well, iJvm is not a real chip but rather a didactic thing), where similar instructions are used to program the internal "code-space" (a physical flash in the case of Avr8)

I guess the code space could appear as a word or two in peripheral space, or mapped into data space: it only needs to be written, only rarely, and only as sequential writes rather than random ones.

Just mulling over what advantages Harvard might have...
- instruction fetch doesn't interfere with data bandwidth
- instruction width decoupled from data width
- two address spaces is more roomy for a given size of pointer
- separation of code and data might be safer
- simpler machine (maybe!)

Is that about right?