Beeb FPGA

[hoglet]

So, what is the approved way to resolve this?
E.g. feed CLOCK_50 into multiple SIGNALS and then feed these into the PLLs?

I'm not an Altera expert either!

But, this does seem to be a rather nasty / fundamental limitation of Cyclone II:
https://www.alteraforum.com/forum/showthread.php?t=6399

And it's why the DE1 feeds the same clock in on multiple pins. Shame they forgot this trick on the DE2!

It's worth googling the exact error message, just to see if there is an easy answer, but I suspect not.

I can think of a few ways to work around this (in order of difficulty):

1. Use one PLL to go from 50MHz to 32MHz and a second PLL to go from 27MHz to 24MHz (and drop the second scan doubler).

2. Use one PLL to go from 50MHz to 96MHz, then a /3 counter to get 32MHz and a /4 counter to get 24MHz.

3. Use a fast counter to generate a 24 and 32MHz clocks that are not quite regular, but have the right average frequency. See here for an example. This is quite hard to get your head around, so I'd try the others first.

You are getting a bit of a baptism of fire here!

Dave

[adrm]

That's a strange limitation, given that the board has 4 PLLs?

I'll try option 1 first

[hoglet]

That's a strange limitation, given that the board has 4 PLLs?

It's a design flaw in the DE2 board, rather than the Altera EP2C35. They should have connected each clock to multiple clock input pins, like they did on the DE1.

It's worth remembering the Cyclone II architecture was introduced in 2004, so it's now 13 years old. The newer devices have much more flexible PLLs.

Dave

[adrm]

The DE2 looked like a good purchase on eBay when I looked at number of LEs and IO pins, but in hindsight, maybe not.
In a positive note, it didn't cost all that much and I guess it's good enough for learning the ropes.

I'll possibly shop around for a Cyclone IV when I have learned more

[adrm]

I now have MODE 7 working somewhat.

The display is quite unstable with a lot of flickering.
Also, characters in the leftmost column of the screen keep flickering on and off in the rightmost column.

I mobile phone photo won't capture the flickering at all.

I'll venture a guess that there is a problem with my generated clock signal?
In theory a multiplicator of 8 and divisor of 9 should be spot on, though.

[hoglet]

27 * 8 gives fVCO of 216MHz which is too low.

It might actually be possible to generate all three clocks using two PLLs as follows:

PLL1:
- start with 27MHz
- use m=32,n=1 to get fVCO of 864MHz
- use c1 = 27 to get 32MHz
- use c2 = 32 to get 27MHz

PLL2:
- start with 50MHz
- use m=12,n=1 to get fVCO of 600MHz
- use c1 = 25 to get 24MHz

This seems to be the best document for the Altera PLLs:
https://www.altera.com/en_US/pdfs/liter ... i51007.pdf

Each PLL has three separate outputs.

The limits seems to be:
- fVCO has to be between 300MHz and 1000MHz
- m is 1..32
- c1, c2, c3 are 1..32

Are you manually editing the PLLs or using the wizard?

Dave

[adrm]

27 * 8 gives fVCO of 216MHz which is too low.

Are you manually editing the PLLs or using the wizard?

Dave

Using the Wizard seemed the prudent course, given my lack of competence

[hoglet]

OK, so two further alternatives (on paper anyway):

=========================================

PLL1:
- start with 27MHz, and pass this through
- use m=32,n=1 to get fVCO of 864MHz
- use c1 = 27 to get 32MHz

PLL2:
- start with 50MHz
- use m=12,n=1 to get fVCO of 600MHz
- use c1 = 25 to get 24MHz

========================================

PLL1:
- start with 27MHz, and pass this through
- use m=16,n=1 to get fVCO of 432MHz
- use c1 = 18 to get 24MHz

PLL2:
- start with 50MHz
- use m=16,n=1 to get fVCO of 800MHz
- use c1 = 25 to get 32MHz

The second of these is very close to what you have, just using 16/18 instead of 8/9

Dave

[adrm]

I've scratched my head trying to figure this out for a while now.
Too late ... brain turning to mush ... ZZZZ

I'll give it a go again, tomorrow morning.

[adrm]

From the PLL guide:

Each PLL can be fed by one of four single-ended or two differential clock
input pins. For example, PLL 1 can be fed by CLK[3..0] when using a
single-ended I/O standard. When your design uses a differential I/O
standard, these same clock pins have a secondary function as
LVDSCLK[2..1]p and LVDSCLK[2..1]n pins. When using differential
clocks, the CLK0 pin’s secondary function is LVDSCLK1p, the CLK1 pin’s
secondary function is LVDSCLK1n, etc.


Does this help us at all?
I don't know what a single-ended clock is, but the text seems to indicate that you can share e.g. the 50MHz clock among PLLs. E.g. CLOCK_50(0) and CLOCK_50(1).
Or am I grasping at straws here?

[hoglet]

Each PLL can be fed by one of four single-ended or two differential clock
input pins. For example, PLL 1 can be fed by CLK[3..0] when using a
single-ended I/O standard.

Does this help us at all?

I don't know what a single-ended clock is, but the text seems to indicate that you can share e.g. the 50MHz clock among PLLs. E.g. CLOCK_50(0) and CLOCK_50(1).
Or am I grasping at straws here?

All this is saying is that there each PLL can be driven by a choice of 4 different external pins.

This is the relevant diagram:

On each side of the chip, in the middle, are the 4 possible clock input pins. But those 4 clock input pins all connect to the same PLL. e.g. CLK[0..3] all connect to just PLL1.

I think the solution here is to use the PLLs as follows:

PLLA:
- start with 27MHz and pass this through (the clock control block allows direct use of the clock input)
- use m=16,n=1 to get fVCO of 432MHz
- use c1 = 18 to get 24MHz

PLLB:
- start with 50MHz
- use m=16,n=1 to get fVCO of 800MHz
- use c1 = 25 to get 32MHz

Dave

[adrm]

I'm trying to wrap my brain around how the PLLs work, and failing.

The guide you linked to a few post above seems (to me) to say that:

• There is 1 m (multiplier) per PLL
  There is 1 n (divider) per PLL
  These operate on the fREF to give a fVCO

It then goes on to say:
Each output port has a unique post-scale counter to divide down the
high-frequency VCO. There are three post-scale counters (c0, c1, and c2),
which range from 1 to 32.

However, the MegaWizard dialogue screens give the impression that you have a N and an M for each of C0, C1 and C2, which would seem to contradict the above(?)

Maybe my failure of reasoning is that I have regarded C0, C1 and C2 as end products, i.e. output clocks to be used by various elements in the design? I hesitate because of the manual's wording where C0 etc, are called "post scale counters" not e.g. "clock outputs"?

I guess this confusion can be cleared up with a bit more study, but it connects directly to my failing to understand how your suggestions work.
I.e.
- use m=16,n=1 to get fVCO of 432MHz ---> Yes, I can set this up
- use c1 = 18 to get 24MHz ---> Ehhh? *lots of head scratching*

[hoglet]

I guess this confusion can be cleared up with a bit more study, but it connects directly to my failing to understand how your suggestions work.
I.e.
- use m=16,n=1 to get fVCO of 432MHz ---> Yes, I can set this up
- use c1 = 18 to get 24MHz ---> Ehhh? *lots of head scratching*

I think this is confusing because the Wizard generally tries to hide the actual values of m, n and c, and instead shows the multiplier / divider ratio in it's simplest form.

Let's back up a bit...

My understanding is a Cyclone II PLL has:
- one clock input (frequency Fin)
- up to three clock outputs
- one multiplier (they call this the M counter, values 1..32)
- one pre-scale divider (they call this the N counter, values 1..32)
- three post-scale dividers, one for each clock output, (they call these the c1, c2, and c3 post scale counters, values 1..32)

The frequency of output clock 1 is (Fin * m) / (n * c1)
The frequency of output clock 2 is (Fin * m) / (n * c2)
The frequency of output clock 3 is (Fin * m) / (n * c3)

Here's an example, a PLL with:
- input clock of 27MHz
- output clock 1 of 24MHz
- output clock 2 of 27MHz
- output clock 3 unused

Here's the run through the ALTPLL wizard:

The interesting screen is this one:

I've told it I want the output frequency for Clock c0 to be 24MHz, and it's presented the multiplication factor as 8, and the division factor as 9.

But if you scroll around the little info box, you'll see the real values are:
- fVCO = 648MHz
- M counter = 24
- N counter = 1
- c0 post scale counter 27

It's picked 24/27 rather than 8/9 to ensure the frequency of the VCO (= Fin * m / n) is in the required range (300MHz to 1000MHz)

Is that any clearer?

Dave

P.S. Your picture of MODE 6 text looks perfect! The character rounding you might be remembering is only in MODE 7.

[hoglet]

This picture is a very good summary of the structure of the Altera Cyclone II PLL:

Source:
https://www.altera.com/content/dam/alte ... i51007.pdf

In my description above, I've ignore k (the VCO post scale counter), which is not to be confused with the individual clock post scale counters. For now, just assume it's value is 1 (i.e. it's not there!)

The four possible clock inputs on the left correspond to physical input pins on the device. On the DE2, only one of these wired up.

Dave

[adrm]

Let's back up a bit...


Is that any clearer?

Dave

P.S. Your picture of MODE 6 text looks perfect! The character rounding you might be remembering is only in MODE 7.

Thank your for taking the time to go into detail, Dave. This is proving to be just as much fun as I had expected. I hope it's not too frustrating and time consuming to you. I expect you'll let me know when you've had enough


What you show above is exactly what I had set up, so I'm probably just confusing myself at this point.

Just one more question for the moment.
You say:
PLLA:
- start with 27MHz and pass this through (the clock control block allows direct use of the clock input)
- use m=16,n=1 to get fVCO of 432MHz
- use c1 = 18 to get 24MHz

Does the underlined part mean that I can use the 27MHz clock BOTH as input to a pll AND as a clock input for other parts of the design, i.e. in paralell with the pll?
Or am I misinterpreting and you're saying that IF the 27MHz clock is fed into a PLL, it MUST be also passed though the pll and output from this without conversion (along with the scaled 24MHz signal)?

[hoglet]

Just one more question for the moment.
You say:
PLLA:
- start with 27MHz and pass this through (the clock control block allows direct use of the clock input)
- use m=16,n=1 to get fVCO of 432MHz
- use c1 = 18 to get 24MHz

Does the underlined part mean that I can use the 27MHz clock BOTH as input to a pll AND as a clock input for other parts of the design, i.e. in paralell with the pll?

Yes, that's correct, at least for Altera FPGA.

BTW, I'm just having a go at this myself (i.e. using a PLL to go from 27MHz to 24MHz).

Just to make sure there are no further gremlins.

Edit: Which it seems there might be, as I'm currently experiencing a very unstable mode 7 display doing this (the columns of flickering/ghosting characters)

Dave

[adrm]

BTW, I'm just having a go at this myself (i.e. using a PLL to go from 27MHz to 24MHz).

Just to make sure there are no further gremlins.

Edit: Which it seems there might be, as I'm currently experiencing a very unstable mode 7 display doing this (the columns of flickering/ghosting characters)

Dave

Yep, sounds like what I'm seeing at my end

[hoglet]

Tore,

I've pushed a commit to github that updates the bbc_micro_de1 design to use only the 27MHz clock.
https://github.com/hoglet67/BeebFpga/co ... ae02b0b789

Yesterday you reported:

I now have MODE 7 working somewhat.

The display is quite unstable with a lot of flickering.
Also, characters in the leftmost column of the screen keep flickering on and off in the rightmost column.

I just hit exactly the same problem, when I initially tried:
PLL1: 50MHz -> 32MHz (system clock)
PLL2: 27MHZ -> 24MHz (teletext clock)

Then I remembered, as in the real beeb, the teletext clock needs to be phase locked to the system clock. And this can't happen if two independent PLLs with independent crystal oscillators are used.

So in an ideal world, we would use one PLL to generate both, i.e.
PLL1 50MHz -> 32MHz, 24MHz
or
PLL1 27MHz -> 32MHz, 24MHz

But it turns out neither of these combinations are possible within the constraints of the Altera PLL. Either fVCO is too high, or the post scale counter needs to be set to a value larger that 32.

What I ended up doing was:
PLL1: 27MHz -> 32MHz, 48MHz

then using a counter to divide the 48MHz clock by two to get 24MHz.

That seem to work as well as my original clocking scheme, so I've committed that back to github.

One more thing... Mode 7 when using sRGB mode to a SCART TV looks perfect, and is indistinguishable from a real Beeb:

Mode 7, resampled to VGA by the scan doubler, looks not so great!

Some of the uprights, e.g. the on the M, end up different widths. This is caused by resampling the 12MHz teletext pixels with a 32MHz VGA clock.

Dave

[fordp]

I just rebuilt the DE1 version of this core. I would play with it if I could find my ps2 keyboard It builds OK and seems to run.

I just noticed the Papilio DUO link was out of date on the wiki so hopefully I have fixed that assuming the old board had 512K of RAM?

[fordp]

I just rebuilt the DE1 version of this core. I would play with it if I could find my ps2 keyboard It builds OK and seems to run.

I just noticed the Papilio DUO link was out of date on the wiki so hopefully I have fixed that assuming the old board had 512K of RAM?

P.S. I have found my keyboard and Carnival works

[adrm]

I implemented Dave's changes this afternoon, but nothing worked.
I felt sure it had to do wilt the new PLL, because I'd checked everything else, but I just couldn't see the problem.

During dinner it dawned on me, and when I checked, I saw that I'd forgotten to alter the input clock from the old 50MHz to the new 27MHz.

So now it works.

The mode 7 display looks pretty awful, as Dave found.
Apart from the question of "is it worth the effort", I'm wondering if this is fixable, or just a limitation one has to accept?

Reading SD cards:
Is there a limitation on what one can use?
The only spare I found at the moment is 2GB Micro SD in a SD adapter.

I works fine in a phone and on a PC, but the Beeb FPGA stubbornly refuses to recognise it, and gives me the CARD? message when I do *.
I have tried *MMFS

Does the MMFS read FAT, or is there a files system embedded in the file BEEB.MMB?
The way I have read the instructions you:

• 1-Format the SD card with FAT or FAT32 (Tried both)
  2-Copy e.g. BEEB.MMB onto the card, making it a file in the FAT fs
  3-Insert into Dev. board
  4-Do *MMFS
  5-Do *.

[hoglet]

The mode 7 display looks pretty awful, as Dave found.
Apart from the question of "is it worth the effort", I'm wondering if this is fixable, or just a limitation one has to accept?

If you compare to the pictures I posted earlier, is what you are seeing the same, or worse?

The problem with MODE 7 mapped to VGA boils down a combination of:
- the weird 480x500 resolution of Mode 7, c.f. 640x512 in other mode
- this not scaling "nicely" to a VGA resolution (e.g. at 720x576 or 800x600, 1 pixel maps to 1.5 pixels)
- alternatively, if you scale pixels 1:1 the screen looks very squashed
- doing anything clever (e.g. using a higher VGA resolution) would require a whole frame buffer, which is infeasible in a small FPGA.

There's more in this thread:
http://www.stardot.org.uk/forums/viewto ... 00#p124300

If anyone has any ideas, I'm happy to experiment.

You need to get yourself a TV with a SCART input. The sRGB mode is indistinguishable from a real Beeb. Do they exist in Norway?

BTW, I do have another project, using a Raspberry Pi Zero to convert sRGB to HDMI, and this does a rather better job. This works with an original Beeb, so should work with BeebFPGA.

Reading SD cards:
Is there a limitation on what one can use?
The only spare I found at the moment is 2GB Micro SD in a SD adapter.

I works fine in a phone and on a PC, but the Beeb FPGA stubbornly refuses to recognise it, and gives me the CARD? message when I do *.
I have tried *MMFS

Does the MMFS read FAT, or is there a files system embedded in the file BEEB.MMB?
The way I have read the instructions you:

• 1-Format the SD card with FAT or FAT32 (Tried both)
  2-Copy e.g. BEEB.MMB onto the card, making it a file in the FAT fs
  3-Insert into Dev. board
  4-Do *MMFS
  5-Do *.

The Card? error usually means a hardware issue with the interface.

Have you double-checked the pin assignment to the SD Card port are correct?

Edit: I think you are missing pin assignment for the SD card signals used by BeebFPGA in your .qsf file.

Try changing:

Code: Select all

set_location_assignment PIN_AD24 -to SD_DAT
set_location_assignment PIN_AC23 -to SD_DAT3
set_location_assignment PIN_Y21 -to SD_CMD
set_location_assignment PIN_AD25 -to SD_CLK

to

Code: Select all

set_location_assignment PIN_AD24 -to SD_MISO
set_location_assignment PIN_AC23 -to SD_nCS
set_location_assignment PIN_Y21 -to SD_MOSI
set_location_assignment PIN_AD25 -to SD_SCLK

Dave

[hoglet]

BTW, I expect the SD pin misassignments is the reason LED R13 lights up when you press BREAK.

[adrm]

If you compare to the pictures I posted earlier, is what you are seeing the same, or worse?

Umm ... now that I actually compare to your picture, I'd have to say mine looks better.
For example, the legs of an M have the same width.

I haven't fired up my real Beeb in a while, due to space limitations, so it's possible I my memory of MODE 7 characters is off.

You need to get yourself a TV with a SCART input. The sRGB mode is indistinguishable from a real Beeb. Do they exist in Norway?

I guess you can find cheap TVs with SCART inputs, but there are none where I'm staying at the moment (90% of my belongings are in storage after I sold off my house, and I've been living in a limbo contemplating relocation to a better climate *sigh*)
I'm stuck with whatever fits on a single desk, for now.

BTW, I do have another project, using a Raspberry Pi Zero to convert sRGB to HDMI, and this does a rather better job. This works with an original Beeb, so should work with BeebFPGA.

I have multiple PI3s lying around, if you need another tester

Try changing:

Code: Select all

set_location_assignment PIN_AD24 -to SD_DAT
set_location_assignment PIN_AC23 -to SD_DAT3
set_location_assignment PIN_Y21 -to SD_CMD
set_location_assignment PIN_AD25 -to SD_CLK

to

Code: Select all

set_location_assignment PIN_AD24 -to SD_MISO
set_location_assignment PIN_AC23 -to SD_nCS
set_location_assignment PIN_Y21 -to SD_MOSI
set_location_assignment PIN_AD25 -to SD_SCLK

Dave

That worked, but now it's complaining about "Card Format?"
I assume this means it has problems reading the SD card file system? I believe I formatted it to FAT32 the last time.

[BigEd]

There's this comment elsewhere:

A lot of other projects recommend using the official SD Card formatter program:
https://www.sdcard.org/downloads/format ... a_windows/

[hoglet]

That worked, but now it's complaining about "Card Format?"
I assume this means it has problems reading the SD card file system? I believe I formatted it to FAT32 the last time.

Seems formatting in Windows 7/10 can be problematic.

Try reformatting the card with "SD Formatter" from the SD Association:
https://www.sdcard.org/downloads/formatter_4/

FAT32 should be OK.

If that fails, then it might be worth updating MMFS to a newer version (I think you have 1.25 if you do *HELP).

Edit: You've possibly hit the issue resolved by this fix:
https://github.com/hoglet67/MMFS/commit ... daafb42645

Dave

[adrm]

SD Formatter saved the day.

I have used this program in the past, with a Pi3, iirc. But with the Pi, PC formatting did just as good a job, so I never gave it another thought.

Well, it seems everything is in working order now.
If anyone wishes to add this to GITHUB, feel free (I don't have an account). Maybe there is another DE2 newbie out there
(I should probably try to rename the project to "bbc_micro_de2" first, though?)


I can now start studying the Beeb project code and pick up more VHDL pointers. Good times!

Again, thank you very much Dave (and anyone else who contributed)
It's not entirely unlikely that I have the odd question, now and then.

[hoglet]

If anyone wishes to add this to GITHUB, feel free (I don't have an account). Maybe there is another DE2 newbie out there

If you could upload the working code to dropbox, I might have a go at adding this in next week. It's always tricker to get a new target working than you might first imagine. Lots of traps for the unwary, but a great learning experience (for me as well!).

Dave

[fordp]

Fingers crossed that 2018 can be the year I finally get a reliable FPGA based Beeb/ Spectrum. My first computer was a 16K Spectrum. My brother gave me a BBC system just over a year after that. Next year I should get my Spectrum Next.

A port of Beeb FPGA would be the making of it for me. I have a software project planned for next year to run on the PiCopro.

I will have to wait a little longer as I could not resist getting the cased version.

[adrm]

I have now ZIPed up the latest DE2 file structure and shared it here: https://www.dropbox.com/s/kchclfcwk5bdj ... 2.zip?dl=0

A few notes:

1. I disabled the video mode switches (SW7 and SW8) as they are likely to cause pain for anyone new. 8 down and 7 up is now locked. I left the code in, if anyone wishes to tinker with it in the future
2. I renamed the project "bbc_micro_de2"
3. The Xilinx directories are stillther, unaltered
4. The Altera/db directory has grown a lot, and probably needs cleaning out. I didn't dare mess with it, at the moment, though.