UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Television Standards Converters, Modulators etc

Notices

Television Standards Converters, Modulators etc Standards converters, modulators anything else for providing signals to vintage televisions.

Closed Thread
 
Thread Tools
Old 9th Dec 2010, 3:43 pm   #21
ppppenguin
Retired Dormant Member
 
ppppenguin's Avatar
 
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
Default Re: 819 line standards convertor.

Quote:
Originally Posted by tubesrule View Post
Alternatively you can recast the SLV

conv_integer_range(hcs) >= 63
I like the idea of casting the SLV purely for the comparison but surely the correct construct is: conv_integer(hcs)
ppppenguin is offline  
Old 9th Dec 2010, 5:26 pm   #22
tubesrule
Hexode
 
tubesrule's Avatar
 
Join Date: Jul 2004
Location: Michigan USA
Posts: 325
Default Re: 819 line standards convertor.

Right you are! My fingers were typing ahead of my brain ;-)
__________________
Aurora video standards converters: http://www.tech-retro.com/Aurora_Design/Video_Home.html
tubesrule is offline  
Old 18th Dec 2010, 11:24 am   #23
pitbuell94
Retired Dormant Member
 
Join Date: May 2009
Location: Fresnes, France
Posts: 124
Default Re: 819 line standards convertor.

Hi Dear All,

Because I have some difficulties to make a FIFO in VHDL, I'm looking for this IC => FIFO AL422B.

I found some of them in far countries but shipping cost are highter than the part.

Does someone have this chip in Europe.

I've buy the rest of spare parts => LM1881 and EL 4583 => maybee better and TDA 8702, TDA8703 and TDA8708.

Maybee I'll use a EL 4584 to synchronise everything.

Have a good day.

Frédéric Cabanes.

Last edited by pitbuell94; 18th Dec 2010 at 11:50 am. Reason: By mistake, my fingers press too fast the keyboard
pitbuell94 is offline  
Old 18th Dec 2010, 1:14 pm   #24
ppppenguin
Retired Dormant Member
 
ppppenguin's Avatar
 
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
Default Re: 819 line standards convertor.

FIFO is a standard Coregen part in Xilinx Spartan 3A and above. Obviously you are limited by the number of BRAM in your Xilinx but it's easy to make line stores. If you want to make a framestore may I suggest using large fast SRAM chips. I have used SDRAM but the timings are complex.

I have used the AL422 as a framestore and it is very easy to use. I think it is now obsolete.

For your video input I would recommend a decoder chip. This will also solve all the input sync problems. There is (was?) a wide choice. Darryl used the Texas (TI) TVP5150 in the popular Aurora converters and it works very well.

May I recommend that you read both my articles about standards conversion. They are on my website.
ppppenguin is offline  
Old 18th Dec 2010, 5:46 pm   #25
pitbuell94
Retired Dormant Member
 
Join Date: May 2009
Location: Fresnes, France
Posts: 124
Default Re: 819 line standards convertor.

Hi Dear PPPPenguin,

Thank you for all.

I'm going to read your articles.

I hope I understand everything.

This is my first project in vhdl... I hope this try is not too big for me.

I put all I need on paper, so, all the functions I need are clear for me.

But do it in good way is an other thing.

Frédéric Cabanes.
pitbuell94 is offline  
Old 5th Jan 2011, 3:52 pm   #26
pitbuell94
Retired Dormant Member
 
Join Date: May 2009
Location: Fresnes, France
Posts: 124
Default Re: 819 line standards convertor.

Hi Everybody,

I wish you an Happy new year and all the best .

I have a question concerning FIFO.

Is-there a trick to calculate the size of a FIFO.

I'm actually spending time concerning the design of FIFO=> size/depth.

For my design, I'll use 2 FIFO => one to store actual line and one to store prévious line.

The problem is output frequency is highter than input frequency.

With my design, I need 3 lines in 625 to make 4 lines in 819=> ratio is 1.31

In this way, 3 lines in 625 takes 192 µs.
To read 4 lines in 819, it takes 195.36 µs.
There is each time a loop is done for the process an excess of 3.36µs.
So, I need more time to read than time to store.

I think about a buffer of 6 lines but after a while, the write pointer will reach the read pointer and the 2 FIFO will be full .
=> I wait 2 lines of 625 are in the 2 FIFOs and then start to read content of FIFO 1 at 819 clock, after line 1 is readed, I start in same time to read FIFO 1 and FIFO 2 for output line 2 in 819 standart because line 2 in 819 definition is result of average of line 1 and line 2 and line 3 in 819 is average of line 2 and 3, then, I stop FIFO 1 and read FIFO 2 to create line 4 because in the same time, line 3 and 4 are stored in the FIFOs.

During this time, I write like a river flow in FIFO 1 and FIFO 2.
When write pointer reach the end of line 6 in 625, I'll make a reset of write pointer.

This reset of Write pointer occurs each 6 lines.
The reset of Read pointer occurs in the same way every 6 outputted lines.

Line 5, 6, 7 and 8 are then created and during this time, data from 625 comes in both FIFOs.

=> Question to Darryl and PPPPenguin,

Do you think a buffer around 6 lines for process and 6 lines for the excess of process time is enough?

So, I need a Fifo of (6 lines + 6 lines ) * 512 dots per line * 8 bits => 6.144 Kbytes.

Are-you agree with this.

In this case, I need to reset my write pointer every 12 lines and the same for the read pointer=> correct?

Is-there a trick to calculate this?

Have a good day.

Frédéric Cabanes.

Last edited by pitbuell94; 5th Jan 2011 at 4:20 pm. Reason: french fingers go to fast and make mistake...
pitbuell94 is offline  
Old 5th Jan 2011, 4:28 pm   #27
ppppenguin
Retired Dormant Member
 
ppppenguin's Avatar
 
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
Default Re: 819 line standards convertor.

You need a minimum of 3 lines of storage in a simple standards converter. I would recommend that you do NOT use FIFOs. Use dual port memories with address counters. Actually they don't even need to be dual port but the Xilinx BRAMs are inherently dual port and very convenient.

For a down conversion (such as 625 to 405) the first line is written to memory 1, 2nd line to memory 2 etc. Approximately 1 line in 3 is not written at all. The 3 lines are read in sequence. For up conversion (such as 625 to 819) the input lines are written to the memories in sequence. Some lines are read twice from the same memory.

You can get higher quality by using an interpolator. In a 625>405 converter this is fitted before the main line memories. In a 625>819 converter it is after the main memories.

I'm sure Darryl has a more elegant method, possibly using the true dual port capabilities of the Xilinx BRAMs.
ppppenguin is offline  
Old 5th Jan 2011, 7:55 pm   #28
tubesrule
Hexode
 
tubesrule's Avatar
 
Join Date: Jul 2004
Location: Michigan USA
Posts: 325
Default Re: 819 line standards convertor.

Hi Frederic,
You are discovering some of the issues that come up when doing conversions, and there are ways to address or avoid these issues.

First, you shouldn't be thinking in terms of single line FIFO's, but rather multi-line DPRAM's as Jeff mentioned. Also, think in terms of an entire field. You should use one larger memory that can store several lines in a round robin fashion and reset this process at the end of each field. Since fpga's can handle high speeds extremely well, just use a higher speed clock on the output side to read several places in the memory (representing several lines of video) during each pixel cycle. This can be done using a DCM clock multiplier.

Looking at this from a field point of view, assuming you are targeting French System E, there are 369 lines/field while 625 has 288 lines/field. This means the actual ratio between the two is about 1.2812. Using a ratio like your 1.333 does make the design easier in some respects since you can use a fixed interpolator algorithm, but you now have other things to consider. At a 1.333 ratio, 288 input lines would result in 384 output lines which obviously won't fit. To achieve 369 output lines with a 1.333 ratio will require about 277 input lines. This will result in a 288/277 or about 4% vertical stretch in the output, probably not enough to worry about at this point.

So, with 277 input lines at 64us each gives 17.728ms for a complete field. On the output side, 369 line at 48.84us gives 18.022ms. This means the data is coming in faster than it is going out. Looking at the difference, 18.022ms - 17.728ms = 0.294ms or 294us. Since the lines are coming in faster than going out, you need to provide enough memory to store the extra lines as they come in until needed, so 294us/64us ~ 4.6 lines. This means your memory needs to be large enough to store at least 4.6 lines plus the number of lines used in your interpolator, presumably 3 lines, so 7.6 lines total.

At 512 pixels/line and 8bits/pixel, you need 7.6 * 512 = 3892 bytes. Since each BRAM in the Spatan3's are 16kb, (2kB) you'll need to use two of them to create a 4kB DualPort memory in CoreGen.

Darryl
__________________
Aurora video standards converters: http://www.tech-retro.com/Aurora_Design/Video_Home.html
tubesrule is offline  
Old 5th Jan 2011, 8:22 pm   #29
ppppenguin
Retired Dormant Member
 
ppppenguin's Avatar
 
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
Default Re: 819 line standards convertor.

Darryl, I knew you would have better methods. It's so long since I've done standards conversion that I've forgotten the methods I used. Multiport memory is definitely the right way to do it. Write the data once and access it as many times as is necessary. My method with 3 line memories was used on the BBC CO6/509 digital converter. Good fast memories were not available then.

An example with the usual 720 pixels per active line and 13.5MHz clock for the 625 input. The output clock speed for 819 will be about 17.7MHz. It is easy to operate a Spartan 3A device at 4 times this, 71MHz. Hence you can access data from 4 adjacent lines at what appears to be the same time.

A fast clock on the output side is also useful for making an oversampled DAC. This makes the analogue output filter much less critical. Coregen can synthesise oversampling filters. When you want to do this please ask again - I have developed some simple methods for doing this.

I don't know how Darryl locked the output clock to the 13.5MHz input clock. It must be locked unless you use a full frame of memory.
ppppenguin is offline  
Old 5th Jan 2011, 10:03 pm   #30
tubesrule
Hexode
 
tubesrule's Avatar
 
Join Date: Jul 2004
Location: Michigan USA
Posts: 325
Default Re: 819 line standards convertor.

Quote:
Originally Posted by ppppenguin View Post
An example with the usual 720 pixels per active line and 13.5MHz clock for the 625 input. The output clock speed for 819 will be about 17.7MHz. It is easy to operate a Spartan 3A device at 4 times this, 71MHz. Hence you can access data from 4 adjacent lines at what appears to be the same time.
Exactly. Taking advantage of the speed of the fpga, particularly the BRAM's is a great way to simplify a design. Parallel design methods come into play when you just can't run the part any faster, so you need to go wider.

Quote:
Originally Posted by ppppenguin View Post
I don't know how Darryl locked the output clock to the 13.5MHz input clock. It must be locked unless you use a full frame of memory.
On the SCRF converters I run the output anywhere from 3X to 4X the input. The output clock is locked to the input clock and multiplied using the DFS's in the DCM's. The jitter out of the video decoder is low enough for them to lock.

On the World Converter I have 8 full frame memories, so it can run open loop or locked depending on a user setting.

Darryl
__________________
Aurora video standards converters: http://www.tech-retro.com/Aurora_Design/Video_Home.html
tubesrule is offline  
Old 6th Jan 2011, 12:11 pm   #31
pitbuell94
Retired Dormant Member
 
Join Date: May 2009
Location: Fresnes, France
Posts: 124
Default Re: 819 line standards convertor.

Hi Darryl and PPPPenguin,

Greats thanks concerning all these informations.

So now,I have to decide what kind of way I'll use for me design.

I have enough spare part to do all of these.

I have fast memories > 20ns => CYM1420HD
some UM61256, TC551001 and concerning FIFOs, I have a big stock of IDT7203 and CY7C429-40.

Some CXA1096 and TDA8708, 8703.

Now it's time to brainstorming....

Frederic cabanes.
pitbuell94 is offline  
Old 6th Jan 2011, 12:50 pm   #32
ppppenguin
Retired Dormant Member
 
ppppenguin's Avatar
 
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
Default Re: 819 line standards convertor.

To store a few lines of video please use the BRAMs inside the Xilinx. This is much easier than using external FIFOs etc. If you want to make a frame store then you will need external memory chips.

For the video input I would recommend using a decoder chip. Darryl used the Texas TVP5150 which works very well. http://focus.ti.com/docs/prod/folder...vp5150am1.html Analogue video in, digital component video and 27MHz clock out. The only problem you need to solve is programming it using IIC interface.

A hint. Experiment with 625 in and 625 out. This allows you to prove that all of your ADC, Xilinx and DAC are working without the complications of standards conversion. When you are confident that everything works, that you can do line memories, frame memories etc with 625 in and out, then you can try 819 out.
ppppenguin is offline  
Old 6th Jan 2011, 3:55 pm   #33
tubesrule
Hexode
 
tubesrule's Avatar
 
Join Date: Jul 2004
Location: Michigan USA
Posts: 325
Default Re: 819 line standards convertor.

Frederic,
Please do use the BRAM in the fpga for your line stores. You may want to extend the design later on to include external RAM's, but there is no need for that now. Depending on which development board you purchased, you have either a XC3S500E or a XC3S1200E which contain 40kB and 56kB of BRAM respectively. This is far more than required to do a high quality converter. For instance, my SCRF converters use the XC3S100E fpga's which only contain 8kB of BRAM.

You can use these internal BRAM's as either straight RAM or as FIFO's, which ever you are more comfortable designing with. Use COREGEN to create the RAM or FIFO you require.

Darryl
__________________
Aurora video standards converters: http://www.tech-retro.com/Aurora_Design/Video_Home.html
tubesrule is offline  
Old 6th Jan 2011, 4:12 pm   #34
pitbuell94
Retired Dormant Member
 
Join Date: May 2009
Location: Fresnes, France
Posts: 124
Default Re: 819 line standards convertor.

Hi Darryl and PPPPenguin,

I have a XILINX Spartan 3E-500 on a NEXYXS 2 board.

There is something I can't understand=> I had buy the LBE Book "Digital design VHDL" from Richard E. Haskell and there is 2 differents kinds of information about the available RAM in my Spartan 3E-500.

So, I have around 9344 bytes or 46080 bytes of RAM something is not clear.

I'm just finishing to design a FIFO in VHDL.

Now, I'm doing to do work using PPPPenguin way: first : 625 to 625.

I'll avoid using external component.

If you need some CXA1096, I have around 40 units available.

I have also plenty of CMS components (surface mounted components).

If you need some of them, I can send you for free, just shipping cost.

Thank you for all informations.

Frédéric.
pitbuell94 is offline  
Old 6th Jan 2011, 4:26 pm   #35
pitbuell94
Retired Dormant Member
 
Join Date: May 2009
Location: Fresnes, France
Posts: 124
Default Re: 819 line standards convertor.

Hi,

In attached document, the design of the fifo.

I'm not an expert but this seems to be OK with the simulation.

Frederic.
Attached Files
File Type: txt fifo.vhd.txt (2.6 KB, 483 views)
pitbuell94 is offline  
Old 6th Jan 2011, 4:29 pm   #36
ppppenguin
Retired Dormant Member
 
ppppenguin's Avatar
 
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
Default Re: 819 line standards convertor.

The XC3S500E has 20 BRAM blocks, a total of 360kb. The CLBs can also be used to make small RAMs. If you used all the CLBs as RAM you would have 73kb.

A single line of storage needs 720 bytes. A single BRAM configured as 2K*8 will store more than 2 lines. Use COREGEN to make RAM and FIFO easily in any size you want. Then instantiate the RAM or FIFO in your design.

PS: I have added an example of COREGEN files for a RAM 128 words deep and 80 bits wide. It also has a 2nd port which is 20 bits wide and 512 words deep. The VHO file contains information for instantiating the RAM.
Attached Files
File Type: zip KRAM128X80D.zip (24.6 KB, 133 views)

Last edited by ppppenguin; 6th Jan 2011 at 4:36 pm.
ppppenguin is offline  
Old 6th Jan 2011, 4:32 pm   #37
tubesrule
Hexode
 
tubesrule's Avatar
 
Join Date: Jul 2004
Location: Michigan USA
Posts: 325
Default Re: 819 line standards convertor.

Frederic,
The BRAM in the Spartan series can actually be 9 bits wide to allow for parity, so sometimes this causes discrepancies in listed sizes. Your XC3S500E has 20 BRAM's each containing 18K bits that can be configured for many different aspect ratios from 1 bit wide to 36 bits wide. Assuming you use them as 8 bits wide, they are 2KB each, or times 20 of them, 40KB, so you have a lot of BRAM.

Designing your own FIFO's is a good way to get familiar with VHDL and using the BRAM's. Eventually you will just want to use COREGEN to generate modules like this since it will save you a lot of time, and all the optimization for your particular device has already been done.

Darryl

Hmm, I guess Jeff and I cross posted
Attached Files
File Type: pdf Spartan3e 3.pdf (27.0 KB, 218 views)
File Type: pdf Spartan3e 36.pdf (20.9 KB, 233 views)
__________________
Aurora video standards converters: http://www.tech-retro.com/Aurora_Design/Video_Home.html
tubesrule is offline  
Old 6th Jan 2011, 4:52 pm   #38
tubesrule
Hexode
 
tubesrule's Avatar
 
Join Date: Jul 2004
Location: Michigan USA
Posts: 325
Default Re: 819 line standards convertor.

Frederic,
Your code for the FIFO looks fine on the surface, but there are some things you need to be aware of.

In effect, you have implicitly instantiated the actual memory with the line:

type memory_type is array ( 0 to fifo_depth-1 ) of std_logic_vector(wr_data'range);

While there is nothing wrong with this, you have left it to VHDL to decide how to implement this memory. It could use FF's in the CLB's, it could use LUT's in the CLB's or it could use BRAM. If you don't care what it uses, than this is acceptable. In some implementations of VHDL, you can set options to help it decide what to do, For instance in the Xilinx VHDL, you can set a parameter in the Synthesiser HDL options to Automatically extract RAM. This will then use available BRAM if it determines that's what you meant.

A better way is to explicitly use a BRAM by either instantiating it's Map, or using COREGEN to create a RAM of the size and type required.

Finally your Empty and Full logic will not work as defined, and unfortunately this is one of the hardest ideas in logic design to understand; metastability. You can ask Jeff as well, but this will always be a huge issue, and sometimes very difficult to find and fix.

The problem is rd_ptr and wr_ptr are from different clock domains. When you use Empty in your Read process, the wr_ptr will be changing state asynchronously to the rd_clk, so Empty will be metastable. Because of this, it's not as easy as rd_ptr may or may not get incremented correctly, but when this happens, rd_ptr will become corrupt. This is because the actual routing to each FF that makes up rd_ptr will have slightly different timing, and will thus behave differently.

While metastability in this instance can be solved by using a DPBRAM, this is an excellent time to dig in, and understand metastability, it's causes and implications. Xilinx and others have very good papers describing this issue, and it would be worthwhile to take a pause and review some of these. It is a very involved issue, but something you must fully understand to move forward.

Darryl
__________________
Aurora video standards converters: http://www.tech-retro.com/Aurora_Design/Video_Home.html
tubesrule is offline  
Old 7th Jan 2011, 12:16 pm   #39
pitbuell94
Retired Dormant Member
 
Join Date: May 2009
Location: Fresnes, France
Posts: 124
Default Re: 819 line standards convertor.

Hi Darryl and PPPPenguin,

I can see close to me some headake soming soon...and it's not because saturday night fever .

So, if I'm enough clear this morning, you tell me it's little bit dangerous to use my FIFO's design.

Is-there an other way to solve this issue?

Is-there some code to avoid this problem and in wich case this metastability can occurs in my design.

I'm looking for other FIFO code.

As soon I find something, I'll be back.


Frédéric.
pitbuell94 is offline  
Old 7th Jan 2011, 12:33 pm   #40
ppppenguin
Retired Dormant Member
 
ppppenguin's Avatar
 
Join Date: Dec 2003
Location: North London, UK.
Posts: 6,168
Default Re: 819 line standards convertor.

In any design that uses more than 1 clock there will always be metastability problems. General purpose FIFOs have an especially difficult metastability problem. It is very difficult to design reliable FULL and EMPTY flags. Good design minimises metastability problems.

Darryl and I both agree that it is easier to use dual port memory. If the read address crosses the write address you have a problem but it is quite simple to ensure that this doesn't happen. This is a much easier task than making reliable EMPTY and FULL flags for a FIFO.

The classic pulse synchroniser with 2 flipflops is often used to transfer a signal from one clock domain to another. There is an ambiguity of 1 clock cycle but it is a reliable technique. In a standards converter you always need to know the relative positions of input H sync and output H sync. Since input H is on a different clock to output H you need a pulse synchroniser. Then it is easy to measure the relative positions. When you do your design you will find it very important to know if there is 1 pulse of 819 H in a 625 line or 2 pulses.

Experiment with 625 in and 625 out. Then put a dual port memory in the signal path to make a variable delay. If you use a separate output clock you can observe the effect of the read and write addresses crossing. You can make a line store synchroniser. When the read and wrie addresses cross over you will see the picture move up or down by one line.

Last edited by ppppenguin; 7th Jan 2011 at 12:40 pm.
ppppenguin is offline  
Closed Thread

Thread Tools



All times are GMT +1. The time now is 10:42 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.