Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

random phase difference between signals on ICE40

Status
Not open for further replies.

nasdrasil

Newbie
Joined
Dec 25, 2021
Messages
3
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
49
Hi! I'm a starter using FPGA's and was hoping somebody here could point me in the right direction...

To code my iceFUN ice40 HX8K I use icestudio.

I am pulling a 5 bit wide signal into my iceFUN board. This signal contains pixel data from a retro computer. The machine also makes sync with this signal but is missing serration pulses in the vertical interval which makes it unusable on most tv's.

I am using a modeled piece of ROM that creates 3-3-3 bit RGB output. I can verify the output of this ROM with the original signals created inside the machine and they are a perfect match, datawise, timewise and phasewise, which tells me that my modeled ROM is at least functioning the way it should.

Besides the pixel data I want the fpga to create a new, proper sync signal, so I created a seperate module with two counters setup to create the appropriate sync pulses. I use the machines 4mHz clock for this. I can verify my created sync against the machines internally created sync signal. My generated sync on it's own is spot on, but...

Every time on power-up there is a random phase mismatch between the pixel data from the ROM and the sync signal my counters create. It's as if the counters start counting on a random number, but I do set the counter registers to 0. Sometimes sync will be ahead, sometimes behind. ROM and sync generation is both on the machines 4 mHz clock that I pull in.

I am very interested in what could be causing the phase difference between the pixel data and sync signal. The randomness to it is something that puzzles me. I had somebody giving me the clue that my counters had no initial value, so I gave them both an initial value of 0, which did not help my problem.

Not looking for a ready made solution since I consider this a learning project, but it would be great of somebody could point me in the right direction :)
 

Initial value isn't the problem, most FPGA have implicite initialisation of registers to 0 at power-on reset anyway. Obviously your design misses a feature to detect the input sync signal and keeps the counter in phase with it.
 

Initial value isn't the problem, most FPGA have implicite initialisation of registers to 0 at power-on reset anyway. Obviously your design misses a feature to detect the input sync signal and keeps the counter in phase with it.
That is what I thought. One option I could try is to use the original data to recreate sync instead of creating sync from scratch. Or at least use that original signal to start the counter. That would solve the problem probably although it frustrates me not knowing what is causing the current mismatch.
 

You didn't tell how the input signal is generated. It surely involves its own line and pixel counter which is obviously not initialized at the same time as your logic.
 

You didn't tell how the input signal is generated. It surely involves its own line and pixel counter which is obviously not initialized at the same time as your logic.
The input signals (5 of them) come out of the retro machine. I send them though an NVT2006PW voltage level translator to pull them into the ICE40 fpga. The chip they come out of in the old computer is a proprietary one, so I was lucky already to find the pinout I guess. Unfortunately I have no documentation on the logic of this chip.

It's kind of frustrating since I have been stuck at this point for quite some time. I was thinking of recreating the original sync (which is not usable on my OLED tv) just for the purpose of using that as a trigger to start up my counters. I don't mind sync being out of phase. I'm sure I could work with a delay on my counters to dial it in so it will be in phase, but the fact that the phase difference is so random on every boot-up or reset makes me want to find a way to fire up those counters based on the original signals.

What I don't get though is that even if I have an enable signal (created from the original sync) to trigger the counter like down here, still my sync phase difference with pixel data is random at every boot up.

Ideally I'd like the "if(enable)" to be "if(original first syncpulse detected)" or something along those lines. That way at the very least the original data coming from the machine starts my counter and I would have it in thesame place every boot-up or reset... hopefuly...

Code:
reg [8:0] CounterX = 0;

always @(posedge clk)
begin
    if (enable)
        begin
            if (CounterXmax)
                CounterX <= 0;
            else
            CounterX <= CounterX + 1;
        end
end
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top