SHIFTER reimplementation on FPGA

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Wed Jun 27, 2018 6:10 am

ijor wrote:
Smonson wrote:This is fairly stable now, so I'm sharing the verilog model that I'm using.
Spectrum 512 works as long as the pixel count initial value is changed from 4 to 2.


This is probably because you are missing some pipeline cycles between the shift array and the palette lookup. But note that there is no ideal model here. Some programs with Spectrum 512 effects don't work correctly on a real Shifter depending on the wakeup. Furthermore, there is some async behaviour that might even be non deterministic and affected by such things as the temperature.


Yeah, I think you're right there. Also I'm not sure if some of the sequential logic I've used is adding an extra cycle delay in some places (such as the edge detectors) where it makes a difference. Some of this code is still older implementations that work which I haven't got around to investigating whether it can be improved yet, due to a lack of time.

As you can tell from my long silence, I haven't been able to work on this for ages - that's because I unfortunately have a high-priority task that has been sucking up all my evenings for this whole calendar year. But for this week I'm on holidays from work and I've been indulging my hobbies a bit. Eventually the high-priority task will come to an end.

ijor wrote:

Code: Select all

resolution_register <= data;

Ideally this should be cleared on RESET. Not sure if any program actually depends on this, but this is what SHIFTER does.


Thanks, I missed that one.

ijor wrote:As we mentioned some time ago, it is not a very good idea to implement a clock mux like that. And it is not good practice to use the same signal as a clock and as data. The best method is to use the signal as clock enable, not directly as a clock. But if you insist, the FPGA has some dedicated hardware for clock muxing that you might be able to use.

I can infer from your code that you are not simulating the design. It is a bit of a PITA to perform simulations, but trust me, it is worth.


Yeah, I've been ignoring that clock generation part due to a lack of knowledge. I will look into how to do this properly at some point. I've been hoping this message in the console means it's implementing the clocks the best possible way.

Code: Select all

Warning (19017): Found clock multiplexer shifter:shifter_model|pixel_clock


I'm not sure what you mean by using the signal as clock and data.

In place of simulations (another thing waiting on free time) I've been plotting the signals onscreen as the scanline proceeds, which looks like this:

Image

It's a hack but it lets me see what's going on (light blue line is DE, next line is resolution register, then darkened video superimposed with LOAD (red bars) and reload (yellow bars), the red line under that is pixel_counter_enable I think, then lastly the pixel counter expressed as intensity). But you're right, I definitely need to learn how to do it properly.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Wed Jun 27, 2018 6:25 am

ijor wrote:That should not happen, they never overlap except on RESET. They are, at least, one 16MHz cycle apart (so more than one 32 MHz cycle). May be you used something like this:

Code: Select all

   wire reset = load_state == `LOW && !cs;

That is not correct because load_state is registered and cs is not (Did I mention it is worth to simulate ?) :)

In the worst case you might use a counter and trigger reset only if both are asserted together after so many cycles. But honestly, it's not that important.


Nah, I was just using this:

Code: Select all

   wire reset = !load && !cs;


I don't know the reason why it didn't work as expected. Moreover, with the code I am using with the rising LOAD edge, the shifter seems not to always reset properly, especially in monochrome. So it definitely needs to be changed in some way. That's on the to-do list.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Wed Jun 27, 2018 8:16 am

Well, I've spent an hour and a half looking at the simulation function in Quartus, and it seems that version 13 (the last version that supports the Cyclone-II) is buggy and can't run ModelSim. A bit of a dead end unfortunately.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 766
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: SHIFTER reimplementation on FPGA

Postby mfro » Wed Jun 27, 2018 10:02 am

Smonson wrote:Well, I've spent an hour and a half looking at the simulation function in Quartus, and it seems that version 13 (the last version that supports the Cyclone-II) is buggy and can't run ModelSim. A bit of a dead end unfortunately.


Do you try Quartus/Modelsim on Linux or on Windows? Quartus 13.1/13.0 / Modelsim-Altera works fine for me on Linux; just needs some massage with older shared libs if you try to run it on a current version.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby ijor » Wed Jun 27, 2018 12:28 pm

Smonson wrote:As you can tell from my long silence, I haven't been able to work on this for ages - that's because I unfortunately have a high-priority task that has been sucking up all my evenings for this whole calendar year.


Don't worry. This happens to all of us at some point :)

I've been hoping this message in the console means it's implementing the clocks the best possible way.

Code: Select all

Warning (19017): Found clock multiplexer shifter:shifter_model|pixel_clock


No. It is just a warning that a clock mux was detected. If you then go to the manual it would elaborate why that kind of clock mux is not recommended.

I'm not sure what you mean by using the signal as clock and data.


See some extracts of your code:

Code: Select all

   always @(posedge pixel_clock) begin
...
   always @(pixel_clock or load_detect) begin
      if (pixel_clock) begin
         load_detect_delay = load_detect;


The first block is sequential and means pixel_clock is the actual clock of the flip flop(s). At the second block the same signal is used as part of some combinatorial logic. This goes against synchronous design principles. A clock should not be used as data.

Smonson wrote:Nah, I was just using this:

Code: Select all

   wire reset = !load && !cs;


I see. I would synchronize the signals first. Not sure that is actually the problem though.

Well, I've spent an hour and a half looking at the simulation function in Quartus, and it seems that version 13 (the last version that supports the Cyclone-II) is buggy and can't run ModelSim.


It works for me. Note that I rarely run ModelSim from Quartus. I just use it separately and only for functional simulation without Quartus libraries.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Wed Jun 27, 2018 12:34 pm

On 64-bit linux. Yeah, I've got all the library stuff fixed, it is just a problem starting ModelSim itself. It's good to hear that it does work for you mfro, perhaps it is fixable after all.

Code: Select all

ModelSim-Altera was not found. Please install ModelSim-Altera which is included with the Quartus II installer, or use the Quartus II Simulator instead by selecting "Simulation > Options > Quartus II Simulator"


This shows up in the log after generating the netlist, from the waveform editor screen, when I go Simulation -> Run Functional Simulation. The path to ModelSim is correct and I have it set to use ModelSim-Altera in the assignment settings. I can also run vsim from the command-line. I reinstalled ModelSim as well, with no success.

The only results for that error message that I can find on google is that it's a bug in 13.0, fixed in 13.1.

I've downloaded v18, perhaps I can just simulate it in that version and actually work on it with v13.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Wed Jun 27, 2018 12:53 pm

ijor wrote:No. It is just a warning that a clock mux was detected. If you then go to the manual it would elaborate why that kind of clock mux is not recommended.


The manual's another thing that doesn't work for me in Quartus 13, but I read up on glitch-free clock multiplexers earlier and realised that it's not a simple problem to fix. However, I studied the logic diagram of the clock generator that you produced:

Image

But it looks like the shift register at the top is being cleared every clock cycle. I couldn't understand how it works.

ijor wrote:See some extracts of your code:

Code: Select all

   always @(posedge pixel_clock) begin
...
   always @(pixel_clock or load_detect) begin
      if (pixel_clock) begin
         load_detect_delay = load_detect;


The first block is sequential and means pixel_clock is the actual clock of the flip flop(s). At the second block the same signal is used as part of some combinatorial logic. This goes against synchronous design principles. A clock should not be used as data.


Right, I get it. There's a lot of occurrences of this problem, and they can be complicated to unravel. I think it will be better to work backward to eliminate these, replacing the logic that was derived from the decapped circuit blocks with totally new implementations that can produce the same result - if the correct result is known.

ijor wrote:It works for me. Note that I rarely run ModelSim from Quartus. I just use it separately and only for functional simulation without Quartus libraries.


I'm guessing you aren't using version 13.0 though, right?

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby ijor » Wed Jun 27, 2018 1:42 pm

Smonson wrote:The manual's another thing that doesn't work for me in Quartus 13, but I read up on glitch-free clock multiplexers earlier and realised that it's not a simple problem to fix.


I assume you mean that the help system doesn't work, because the manual is a plain PDF file. Yes, the help is picky and might not work depending on your OS, browser, etc. Download the PDF manual.

I wouldn't recommend implementing a glitch free clock mux. It is better to not use an actual clock mux at all. Just use the signal as a clock enable, and not as a clock.

However, I studied the logic diagram of the clock generator that you produced:

Image

But it looks like the shift register at the top is being cleared every clock cycle. I couldn't understand how it works.


Don't bother with that part of the logic. As I commented on the thread, that is just a clever (but not very reliable) method to detect power up and initialize the clock divisor. Yes, those registers are cleared on every cycle. But at power up the reset signal might toggle faster than the clock and then the shift works.

I think it will be better to work backward to eliminate these, replacing the logic that was derived from the decapped circuit blocks with totally new implementations that can produce the same result - if the correct result is known.


That would be ideal, yes. Same functionality with a modern synchronous design.

I'm guessing you aren't using version 13.0 though, right?


I am using version 13.0 as well. I had some old designs for Cyclone II. But on Windows, not on Linux.

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 766
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: SHIFTER reimplementation on FPGA

Postby mfro » Wed Jun 27, 2018 3:43 pm

ijor wrote:
Smonson wrote:The manual's another thing that doesn't work for me in Quartus 13, but I read up on glitch-free clock multiplexers earlier and realised that it's not a simple problem to fix.


I assume you mean that the help system doesn't work, because the manual is a plain PDF file. Yes, the help is picky and might not work depending on your OS, browser, etc. Download the PDF manual.


The help system can be made to work as well. Apparently, this has been done using Adobe WebHelp and there is a patch available (somewhere at Adobe's web site) that fixes the broken Javascript. Anyway, it's questionable if fixing it is worth the effort. The help pages don't have much to say compared to the Quartus pdf docs.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Thu Jun 28, 2018 5:31 am

I got modelsim to work in Quartus 18 in the end, but I find it painful to use. I tried gtkwave today though and it's like magic. Obviously it's basically a toy in comparison to modelsim, but it's literally ten thousand times faster (over 90 seconds vs 6 milliseconds to refresh after editing the verilog). It seems suitable for this task. Thanks for badgering me into getting started with simulation, Ijor :)

Image

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby ijor » Thu Jun 28, 2018 10:57 am

ModelSim can be quite slow. In part there are delays artificially imposed because this is the free version of ModelSim. But also might be because Quartus configure ModelSim for picosecond precision. For functional simulation and unless you want to simulate something like the PLL, nanosecond precision is enough. Add a suitable "timescale" directive.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Sat Jun 30, 2018 9:33 am

An interesting observation:

I downloaded DSView to check Troed's captured LA traces and noticed that the pixels on the real shifter are being generated after the 5th shifter load. That is about 3 pixels later than the simulated result. Same wakestate (1), same setting for pixel_counter's initial value (4).

It's weird because at some point between the 4th and 5th load, the IR -> RR registers copy should have happened. But the first pixel isn't visible for 2-3 pixel clocks after that.

Image
Image

This probably is the reason for the Spectrum 512 dots.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Sat Jun 30, 2018 10:12 am

By the way, I'll keep this on github to avoid making a new post every time the code gets updated. https://github.com/smonson78/st-shifter-verilog

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby ijor » Sat Jun 30, 2018 1:25 pm

Smonson wrote:I downloaded DSView to check Troed's captured LA traces and noticed that the pixels on the real shifter are being generated after the 5th shifter load. That is about 3 pixels later than the simulated result. Same wakestate (1), same setting for pixel_counter's initial value (4).
...
This probably is the reason for the Spectrum 512 dots.


Yes, as I said you are missing a couple of cycles delay between the shifters and the palette lookup. Don't bother too much with the exact timing as seen by the traces though. That's after the palette lookup and at that point it doesn't matter too much. It depends on the resolution, the wakeup (the Shifter wakeup, not the GLUE wakeup), and might be even on the Shifter version.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Sat Jun 30, 2018 2:35 pm

So are bits shifted out of the RRs are going into a shift register before hitting the palette lookup? It affects spectrum 512, so I'd rather have it working.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby ijor » Sat Jun 30, 2018 3:35 pm

Smonson wrote:So are bits shifted out of the RRs are going into a shift register before hitting the palette lookup? It affects spectrum 512, so I'd rather have it working.


Yes, that's what I said earlier. You might need to compensate with the pixel counter start value. Both determine the exact palette lookup timing.

Not sure if I would call that a shift register, it is more that the palette index selection according to the resolution, and the palette lookup are both registered, and you are performing this combinational. It is something like this (not to be taken literally, but more as a seudocode):

Code: Select all

  always @(posedge dotclock) begin
       color <= low_rez ? shift_output[3:0] : shift_output[1:0];
       rgb <= palette[ color];
   end

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Sun Jul 01, 2018 4:33 am

ijor wrote:Yes, that's what I said earlier. You might need to compensate with the pixel counter start value. Both determine the exact palette lookup timing.

Not sure if I would call that a shift register, it is more that the palette index selection according to the resolution, and the palette lookup are both registered, and you are performing this combinational. It is something like this (not to be taken literally, but more as a seudocode):


Thanks, I must have missed it earlier. But I've just added that extra mechanism and that fixes Spectrum 512 while keeping the counter at 4. I can't adjust the counter anymore - I did some tidy-ups to remove "unsafe" paths warned by Quartus which tightened up the timing a bit. Taking it below 4 causes the "every other 16 pixels background" effect on mono and medium res. Because of the faster pixel counter in those modes, the reload_delay signal arrives earlier. 4 seems to be the magic value.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby ijor » Sun Jul 01, 2018 3:40 pm

Great. Now get some compatible HDMI capture hardware and make some video! :)

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Sun Jul 01, 2018 11:50 pm

If by "compatible HDMI capture hardware" you mean a mobile phone camera, I can do that tonight :D

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby ijor » Mon Jul 02, 2018 12:18 am

Nah, I mean an actual capture hardware connected directly through HDMI (or DVI) to your board. I said "compatible" because not every HDMI hardware might accept the signal. Even after your scan doubling, it is still not fully standard. But capture hardware is usually rather tolerant, more than HDMI monitors. So probably most would work.

Edit: But of course, a video taken with a camera is better than nothing :)

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Mon Jul 02, 2018 12:30 am

That's a bit out of my price range.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Sun Aug 05, 2018 8:32 am

Here are pics of Spectrum 512 running on a physical shifter (-38A) for comparison:

At 50Hz:
Image

At 60Hz:
Image

And this is the FPGA model over HDMI at 50Hz (with starburst image loaded):
Image

The FPGA model has the same totally broken results as the physical shifter at 60Hz.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby ijor » Sun Aug 05, 2018 1:36 pm

Smonson wrote:The FPGA model has the same totally broken results as the physical shifter at 60Hz.


Again, it should be the other way around. Please post the disk image you are using. Please make sure you are booting from that image (or physical disk) and not from another one so that it would be easy to compare and to test.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: SHIFTER reimplementation on FPGA

Postby Smonson » Sun Aug 05, 2018 2:00 pm

I will soon (it's midnight here) but it's definitely working at 50 and broken at 60. Maybe they released different versions of the program, or someone modified the copy I have.

ijor
Hardware Guru
Hardware Guru
Posts: 3627
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: SHIFTER reimplementation on FPGA

Postby ijor » Sun Aug 05, 2018 2:14 pm

Smonson wrote:I will soon (it's midnight here) but it's definitely working at 50 and broken at 60. Maybe they released different versions of the program, or someone modified the copy I have.


May be. No big deal anyway as long as your implementation matches what happens with an actual SHIFTER. Would be interesting to see that Spectrum version if you can post it, but certainly no rush.


Social Media

     

Return to “Coding”

Who is online

Users browsing this forum: No registered users and 5 guests