EEVblog Electronics Community Forum
Electronics => FPGA => Topic started by: Yansi on December 23, 2019, 12:54:07 am
-
Hello,
I am having trouble understanding how the SDI video links work at the lowest layer. I have obtained a copy of the SMPTE-259M (SDTV SDI) specification. I understand, data is sent by means of 10bit symbols. I get it, that the serial bit stream is scrambled to increase bit entropy, that it is NRZI encoded so that clock can be recovered more easily.
But how the hell is one supposed to synchronize the transmitter and receiver? So that the descrambler returns back the correct data at the correct time, that it won't fail from a random bit-slip or glitch, etc.
I just don't get it, how that is accomplished. Or is one supposed to use a state machine to catch the SAV/EAV word triplet containing 3FF 000 000 positioned anywhere in the stream, that may come at any point in time to the interface input?
Is there any other SMPTE standard that provides explanation, or am I missing something completely?
Regards,
Y.
-
Maybe I haven't uses the correct google-fu, I have just found this: https://www.cs.york.ac.uk/rts/docs/Xilinx-datasource-2003-q1/appnotes/xapp298.pdf (https://www.cs.york.ac.uk/rts/docs/Xilinx-datasource-2003-q1/appnotes/xapp298.pdf)
Looks promising, currently in the process of digesting this appnote.
//EDIT: Kchool! It seems to address all of my questions so far, including a nifty one about a parallel scrambler implementation.
-
I"ve written an SDI RX and TX modules. IIRC The scrambler self-synchronizes - it just works.
-
Oh, given that Xilinx AppNote I could write you some C code to play with if you like....
-
At a higher level, there are many flavors of video and/or audio transmitted over SDI, so just implementing the lowest bit-packing level does not mean that devices are compatible. For standard-definition, there are both NTSC and PAL versions in both component video (D1) and composite (D2).
-
I"ve written an SDI RX and TX modules. IIRC The scrambler self-synchronizes - it just works.
I am still having trouble understanding how a LFSR can self-sync. But maybe it just works. Somehow. :-//
I am yet to try to write an SDI TX or RX softcore.
At a higher level, there are many flavors of video and/or audio transmitted over SDI, so just implementing the lowest bit-packing level does not mean that devices are compatible. For standard-definition, there are both NTSC and PAL versions in both component video (D1) and composite (D2).
Sure, I know about that. Not currently sure where the difference is between the composite and component signalling (I am yet to do some google-fu into that), but mainly I am interested now in the ST259M-C (270Mbps), which I could potentialy interface with a lot of stuff directly.
//EDIT: It seems that SMPTE 125M and 267M are nowhere to be found on google. Or my google-fu is weak today. Shite!
-
I shouldn't worry too much about the composite variant of SDI. At least here in Europe where PAL is used (I work in film/TV) the quasi-totality of equipment works with the component variant (the first paragraph of Annex B of ST259 states that as well).
Component signals separate each frame into Y (luma), and Cb Cr (chroma components - the blue and red colour differences). YCbCr can be derived from RGB via a matrix + eventual gamma correction (see ITU Rec BT 601(SD) and 709(HD)) . Composite signals combine both luma and chroma into one composite signal, with the chroma on a high frequency carrier and phase shifted per alternate line (PAL). D2 is simply the digital representation of this signal, but is never used today.
Janusz
PS PM sent.
-
Thank you,
I kind of understood the component representation, but still am not sure, how a digital composite video signal is represented. But, I will gladly skip this for now, as also as you write, this stuff is no longer used or supported and I will have enough trouble understanding other things I need. (Stupid question: Isn't it just the PAL composite signal sampled directly?)
I still have kind of confusion in my head about what the exact differences between YUV, YCbCr and YPbPr are, I should probably study more more about that in the ITU-R BT.601 spec. There is also an extensive article about this on Wikipedia, so I will give it a go.
Now I need to familiarize myself with the FPGA and start working on a PCB, so I can start experimenting.
I was thinking about using the cheaply Cyclone IV (EP4CE6E22C8N or EP4CE10..) to make a simple toy board, that should probably utilize the following:
Some 16b 100MHz+ SDRAM,
SDI 259M output,
SDI 259M input (likely two of those?)
CVBS input sampled using TVP5150 (have couple of those),
RGB output (probably DVI-I, have some chips to interface this too).
And some miscellaneous IO, whatever will left.
>=100MHz x16 SDRAM should have enough bandwidth for this application I guess (at x16 width, one video signal is just 13.5MTU/s)
Is this a good or bad idea or why? Any things to consider? Any interesting considerations for useful peripherals round the FPGA?
(After reading a couple of appnotes about SDI receivers, it seems they mostly use external VCOs + loop filters with a phase detector within the FPGA fabric to recover the incoming clock, so I am counting with this also).
-
If you have any desire to store and read HD video from SDRAM the required memory bandwidth ramps up pretty quickly, esp if you convert 422 pixels to 444 (so each pixel has all its colour data).
-
I"ve written an SDI RX and TX modules. IIRC The scrambler self-synchronizes - it just works.
I am still having trouble understanding how a LFSR can self-sync. But maybe it just works. Somehow. :-//
Most LFSR scramblers used for whitening in comms protocols self synchronise.
-
All I plan to have available are up to 3 video inputs and two outputs.
I do not think, I need to convert from 422 subsampling to 444 or even pure 24bit RGB, to attempt any kind of seamless video switching.
I intend the memory to only serve as framebuffer for synchronizing all inputs to a common output. The most memory intensive thing I can currently imagine, is writing all 3 inputs simultaneously, while reading all 3 at once. That means 6 streams of 13.5MTU/s, about ~81MTU/s. Even cheap SDR-SDRAM can be clocked well above 100MHz, leaving probably still enough BW to accomodate for the overhead and bank switching.
Please mind you I am an FPGA and VHDL beginner and certainly won't be doing any fancy stuff with it soon, so every little bit will be a good success. :popcorn:
All available video inputs will be 422 subsampled, the only SDI output will also be subsampled. I (currently to my best imagination) think I will not need to convert the color space nor the subsampling to full 444 samples.
-
Are you sure you have those memory calculations are 'in the ballpark' right? They seem very low... Care to show your workings?
-
One SDTV video is just 27M x 8 per second data in the active part of the video (13.5MHz luma+chroma sample pairs). I will only use 8bit sample resolution, for simplicity. Will not use full 10bit precision of SDI.
One outcoming video from the memory is the same bitrate.
I plan to have only 3 video inputs to the FPGA (2x SD-SDI, 1x CVBS analog through TVP5150, which provides the same 8-Bit YCbCr 4:2:2)
I need to put at least two of those video inputs into a long memory buffer, to be able to sync the video inputs together. So we have at least two streams writing to memory (likely all three).
I need at least two streams reading out of the memory: One for the main video output (SD-SDI encoder), one for what might end up as multi-view output. Three output streams, if I'd want to mix/colorkey/whatever two outputs together.
Giving in total: 3x read stream, 3x write stream, 27MByte/s each. Having a 16bit wide SDRAM, I need 13.5M transfers of data each second. Times 6 streams at once equals about ~81MTU/s or 162 MByte/s.
A cheap 2Mx16x4 SDRAM such as IS42S16400 (http://www.issiusa.com/pdf/42S16400.pdf) can be clocked up to 166MHz for the -6 speed grade. So either I could run it at 5x or 6x the video clock of 27MHz to remain synchronous with required video data rates, 135 or 162Mhz for the -7 or -6 speed grades respectively.
I know that determining the real data throughput of an SDRAM is a complex task, requiring precise knowledge of how it will be used. Keine Ahnung right now, but requiring only 162MByte/s maximum from a memory with theoretical bus speed of up to twice that (16bit wide bus) sounds reasonable, doesn't it?
-
162MByte/s maximum from a memory with theoretical bus speed of up to twice that (16bit wide bus) sounds reasonable, doesn't it?
It does sound reasonable. I was fretting that you were targeting something other than SD-SDI which is 720x576@25Hz, or 270Mb/s.
For the SDRAM throughput calculations, you need to have refresh cycles, which will eat up about ~1% of bandwidth, and also random reads and writes are relatively slow on SDRAM - each time you move to a new row you have issue a "precharge" and the "active" command, taking about half a dozen cycles or so before you can issue the 'read' or 'write' command.
Because of this you have to batch writes that are in the same area of RAM to get good performance - optimal when streaming data would be writing whole columns at a time - giving 6 cycles of overhead over 256 cycles of data transfer, or about 2.5% overhead.
As a back of an envelope calculation, a well designed system might loose 10% of the bus bandwidth to overheads (six cycles of overhead for transferring 64 words). A poorly designed system, which does random single-word accesses might realize less than 20% of the data bus bandwidth.
Given that you are writing multiple streams into differing addresses, it would take a lot of design work (i.e. deep data FIFOs, bus arbiters, and optimally aligned transfers) to get really good results. I would plan on having 50% more bandwidth than you intend to use for your application. You will most likely need enough to have three frames for each source in the buffer (one being written to, one being read, and one either waiting to be filled or emptied). At 0.5MB per frame that needs 4.5MB of SDRAM - so that 64Mb part seems ideal.
The most challenging part would be what to do when the incoming streams are running at a few parts-per-million difference from the local clock. For the video you will either have to drop or duplicate frames, but that would upset the embedded audio streams...
-
In the end I would sure like to attack the HD/3G-SDI standard, but small steps first. ^-^
I am kind of familiar with SDRAM operation. I have never wrote any SDRAM driver in VHDL, but have worked with SDRAM controller equipped microcontrollers in the past, so the principles of the activation/precharging and working with banks is kind of familiar. This HW exercise will certainly be a beneficial extension of my practical knowledge.
Yes of course, the SDRAM would need to be read in bursts or even whole rows, while using the internal RAM blocks in the FPGA as a short buffer stage to smooth out those time where SDRAM can't provide data. But that will be some future project to hack together.
First I need to design the PCB for it, hence need to figure out all required stuff first. What I currently miss and is my huge knowledge gap, is how to recover the receiver clock from the incoming bit stream.
I have found a bunch of relevant appnotes from Xilinx, which shows either external CDR (pretty expensive and obsolete chip) or internal one, while using an external VCO and loop filter.
[attachimg=1]
I guess this is the only reasonable way to get it done, without using unobtainium old ICs or hell expensive overkill ones. What I don't see or understand, is how the phase detector is made inside the FPGA fabric.
Brief google-fu session brought me to "bang-bang" or "Alexander" phase detector, which seems to be suited for recovering clock from a NRZI encoded streams:
[attachimg=2]
However, I see quite an issue in the fact one of the flip flops needs a negative clock edge (almost impossible to do in an FPGA I guess), so not sure how to attack this one.
Neither do I see how the PLL can get synced to place the data sampling in the middle of the incoming data eye, nor how the loop filter shall be designed (what bandwidth? etc..)
Most "cheap" video mixers/switchers usually don't work with genlocked SDI data sources. What is the common solution to the drift problem in these devices?
//EDIT: Or do I really need to recover the clock at all? I only need the recovered data. Here is an interesting reading: https://www.xilinx.com/support/documentation/application_notes/xapp224.pdf (https://www.xilinx.com/support/documentation/application_notes/xapp224.pdf)
-
The most challenging part would be what to do when the incoming streams are running at a few parts-per-million difference from the local clock. For the video you will either have to drop or duplicate frames, but that would upset the embedded audio streams...
I personally used a TI 27MHz XTAL PLL VCO input reference oscillator in my designs. I tune it slowly with a phase detector on the VS from the chosen source video with my output video VS. Never had trouble with switching sources while never breaking the output video. Video blending is a different story. I would just drop or add a fraction of an audio sample every VS to keep my reference output 48KHz digital audio clock. Loosing/gaining a single field or frame once every few minutes or so is never noticed when blending 2 async sources.
-
I am still having trouble understanding how a LFSR can self-sync. But maybe it just works. Somehow.
I know nothing about SDI but self syncing protocols can be pretty trivial to do.
It doesn't need to be super complicated.
At a basic level you can simply offset by 1 bit every time the frame structure is totally invalid.
So, if it gets out of sync, it automatically re-syncs after n increments.
This can be limited so it doesn't happen on a little random bit corruption but does happen if the entire structure makes no sense.
I have no idea if this is how SDI does it, i'm just saying that self syncing can be super simple.
-
I would not like to dive into the math involved around the LFSR, I'd rather stay with "it just works" and leave it alone.
Currently I need to solve the mystery of data (and clock?) recovery. >:(
//EDIT: see below how SDI does the de/scrambling. There shall be a unique character for sync, 3FF 000 000 (10 bits high, 20 bits low).
[attachimg=1]
-
The most challenging part would be what to do when the incoming streams are running at a few parts-per-million difference from the local clock. For the video you will either have to drop or duplicate frames, but that would upset the embedded audio streams...
I personally used a TI 27MHz XTAL PLL VCO input reference oscillator in my designs. I tune it slowly with a phase detector on the VS from the chosen source video with my output video VS. Never had trouble with switching sources while never breaking the output video. Video blending is a different story. I would just drop or add a fraction of an audio sample every VS to keep my reference output 48KHz digital audio clock. Loosing/gaining a single field or frame once every few minutes or so is never noticed when blending 2 async sources.
I understand that if you want to phase lock to a reference. But I need to extract data (and clock?) from the SDI stream first. i am not sure how to extract the asynchronous serial data from the stream.
I see only two viable options:
1) Use a dedicated PLL (external loop filter + VCO) per each SDI input. (Not sure how to make the phase detector logic and it seems to me a bit clumsy, as I do not need the clock for anything else)
2) Oversample the input data by 4 (using a quadrature clock), which may also work, as per Xilinx XAPP224 (https://www.xilinx.com/support/documentation/application_notes/xapp224.pdf) and extract the data only (which is what can be done for multiple inputs, without dedicated PLLs). Bit more complicated, but no fiddling with PLLs.
-
So this is what I was thinking about doing.
If you count the pins, it is likely all the FPGA (144pin LQFP) can offer. Those few left will be brought out as generic IO, or fitted with some basic useful peripherals of the LED/button/switch type.
If you happen to have any tips on better modern cable equalizer or driver chips for SD-SDI, please let me know. CLC014 and CLC006 are quite old bastards and run from 5V, but can be obtained for $2. I would not like to use any more expensive than that. That 5V supply seems so far the only disadvantage which I can live with.
It is great that Texas offers a replacement LMH0074 for the CLC014, but priced at $18 they can shove them somewhere. One can get a pretty decent FPGA for that price, even couple of the modern 3GHz equalizer chips. Both CLC014 and 006 seem to be available from the eastern sources for about $2.
So, here is what I was thinking about:
[attachimg=1]
//EDIT: I am also thinking about adding an I2S audio codec, if I happen to decide to play with embedded audio within the SDI data streams. Also adding one more SDI output will not hurt (CLC006 costs peanuts and will require just a bit board space for the extra BNC).
-
Is this for an actual product? The TVP5150 is obsolete. I've had decent results with ADV7280's or something from that series..
-
I would not like to dive into the math involved around the LFSR, I'd rather stay with "it just works" and leave it alone.
(https://www.eevblog.com/forum/index.php?action=dlattach;topic=223304.0;attach=897870;image)
Note that ehe encode side feeds back, but the decode side only feeds forwards. Whatever goes into the "encoded video in" terminal has completely cleared from the "decoded video out" terminal after just 10 clock cycles. Therein lies its ability to self synchronise.
-
2) Oversample the input data by 4 (using a quadrature clock), which may also work, as per Xilinx XAPP224 (https://www.xilinx.com/support/documentation/application_notes/xapp224.pdf) and extract the data only (which is what can be done for multiple inputs, without dedicated PLLs). Bit more complicated, but no fiddling with PLLs.
If all you are worried about is 270mbit, 4x clock the input is doable. Also, if you have multiple unused PLLs in the fpga, you can trick them into each running an SDI input even if they weren't designed for serial decoding.
Running a fixed 540mhz serial shift inputs, 2 in parallel per input, 1 on nclk and the other on pclk, basically a DDR ram input, will give you the equivilant to a 1080mhz clocking fpag even if the fpga max is only in the 540Mhz range. You need additional logic to select which n or p input is currently in phase dynamically.
Also, the best solution, there exist generic deser clock recovery ICs which will take in SDI among many formats, output a CLK and 1,2, or 4 bits where you still need to deser the rest in the FPGA, but all the clocking PLL and really high speed signals are taken care of allowing you even higher speeds like 1.5gb and 3gb using only 2-5 FPGA inputs per SDI channel. Same for HDMI, but the IP for that 1 costs big $.
-
Yes, an actual product I will build and play with. I don't care if some of the parts are obsolete, all I care about is to get the most fun out of it while keeping the price low. It won't earn me any $, but gain experience and knowledge, which is why I am doing this exercise. I find the usual FPGA "blinkenlights projects" quite boring, hence came up with this, to make something more unique and probably also useful in the end.
TVP5150 does not seem obsolete: http://www.ti.com/lit/ds/symlink/tvp5150am1.pdf (http://www.ti.com/lit/ds/symlink/tvp5150am1.pdf)
Can be sourced from the usual sources from the east for less than $1, unlike the ADV7280, which costs more than I have payed for the FPGA. But sure, the ADV7280 has 4 analog inputs and likely a better ADC, and can do YPbPr, which may be beneficial for some cases.
What I have in my stash is likely the "NRND" labeled TVP5150PBS. Not sure what the exact difference between TVPV5150-PBS and -AM1 is, likely only some minor software discrepancy between them.
This time I am just reusing what is already in my stash, which is both TVP5150 and the Chrontel CH7302A DVI transmitter, which I like for the reduced/multiplexed data bus, which in this case helps keeping the pin count low.
I do not want to complicate the HW unnecessarily, as my primary learning objective is the FPGA itself and would like to reuse parts I already happen to have.
As for the audio codec, I will use likely a WM8731L, also reusing some leftover stock from other projects.
-
2) Oversample the input data by 4 (using a quadrature clock), which may also work, as per Xilinx XAPP224 (https://www.xilinx.com/support/documentation/application_notes/xapp224.pdf) and extract the data only (which is what can be done for multiple inputs, without dedicated PLLs). Bit more complicated, but no fiddling with PLLs.
If all you are worried about is 270mbit, 4x clock the input is doable. Also, if you have multiple unused PLLs in the fpga, you can trick them into each running an SDI input even if they weren't designed for serial decoding.
Running a fixed 540mhz serial shift inputs, 2 in parallel per input, 1 on nclk and the other on pclk, basically a DDR ram input, will give you the equivilant to a 1080mhz clocking fpag even if the fpga max is only in the 540Mhz range. You need additional logic to select which n or p input is currently in phase dynamically.
Also, the best solution, there exist generic deser clock recovery ICs which will take in SDI among many formats, output a CLK and 1,2, or 4 bits where you still need to deser the rest in the FPGA, but all the clocking PLL and really high speed signals are taken care of allowing you even higher speeds like 1.5gb and 3gb using only 2-5 FPGA inputs per SDI channel. Same for HDMI, but the IP for that 1 costs big $.
You are looking for ICs like these, maybe other ones better suited for SDI also exist: https://www.analog.com/en/products/clock-and-timing/clock-data-recoveryretiming.html (https://www.analog.com/en/products/clock-and-timing/clock-data-recoveryretiming.html) Most of these guys have a built in cable length equalizer as well. The cheapest ones with any data clock rate, meaning SDI capable, are around 25$.
-
Also check the 'Clock & Data Recovery/Retiming' SY87701. The state by name support for the SMPTE SDI data rates, but I don't think it's as high quality as the analog devices ICs though it's function is identical, and it does not have a built in cable length equalizer amp.
https://www.microchip.com/wwwproducts/en/SY87701V#additional-features (https://www.microchip.com/wwwproducts/en/SY87701V#additional-features)
-
2) Oversample the input data by 4 (using a quadrature clock), which may also work, as per Xilinx XAPP224 (https://www.xilinx.com/support/documentation/application_notes/xapp224.pdf) and extract the data only (which is what can be done for multiple inputs, without dedicated PLLs). Bit more complicated, but no fiddling with PLLs.
If all you are worried about is 270mbit, 4x clock the input is doable. Also, if you have multiple unused PLLs in the fpga, you can trick them into each running an SDI input even if they weren't designed for serial decoding.
Running a fixed 540mhz serial shift inputs, 2 in parallel per input, 1 on nclk and the other on pclk, basically a DDR ram input, will give you the equivilant to a 1080mhz clocking fpag even if the fpga max is only in the 540Mhz range. You need additional logic to select which n or p input is currently in phase dynamically.
Also, the best solution, there exist generic deser clock recovery ICs which will take in SDI among many formats, output a CLK and 1,2, or 4 bits where you still need to deser the rest in the FPGA, but all the clocking PLL and really high speed signals are taken care of allowing you even higher speeds like 1.5gb and 3gb using only 2-5 FPGA inputs per SDI channel. Same for HDMI, but the IP for that 1 costs big $.
The mentioned XAPP224 uses quadrature clock to obtain 4 sample points per bit. All clocks are equal to the bit rate, which is 270MHz, not 540MHz - that is unfortunately way out of range of a cheap FPGA such as the Cyclone IV E is. (I think the maximum theoretical limit is about 400MHz according to the databook, for the cheap C8 speed grade)
The FPGA I have only has two PLLs available. As far as I understand, each of the PLL has only up to 5 outputs.
I could probably use just one of the PLLs to produce 270MHz SDI clock, both polarities of the in-phase and both polarities of the 90° shifted clock. Hopefully...
Iknow about those external serdes ICs. But they are either hell obsolete, or cost utter bullshit, like 5times or more the price of the FPGA itself (I have already tried, there is alson the other SDI thread, where I have asked about this). Also, I do not need 3gpbs serdes for 270mbps job. And 270mbps only serdes ICs are no longer made.
SY87701V is of no use for me. I need cable equalizer/receiver. Not a reclocker. Also the price and availability is bullshit and none respectively. There are way better suited ICs from Microchip, such as EQCO30R5. Cost $4, does up to 3Gig. Decent availability from distributors.
Still, good ol' CLC014 is just $2 and fits the job fine.
I am still open to look for any replacement for the CLC014, so far nothing beats the EQCO30R5. But I am reluctant to use a 3gig part where it is not required.
-
2) Oversample the input data by 4 (using a quadrature clock), which may also work, as per Xilinx XAPP224 (https://www.xilinx.com/support/documentation/application_notes/xapp224.pdf) and extract the data only (which is what can be done for multiple inputs, without dedicated PLLs). Bit more complicated, but no fiddling with PLLs.
If all you are worried about is 270mbit, 4x clock the input is doable. Also, if you have multiple unused PLLs in the fpga, you can trick them into each running an SDI input even if they weren't designed for serial decoding.
Running a fixed 540mhz serial shift inputs, 2 in parallel per input, 1 on nclk and the other on pclk, basically a DDR ram input, will give you the equivilant to a 1080mhz clocking fpag even if the fpga max is only in the 540Mhz range. You need additional logic to select which n or p input is currently in phase dynamically.
Also, the best solution, there exist generic deser clock recovery ICs which will take in SDI among many formats, output a CLK and 1,2, or 4 bits where you still need to deser the rest in the FPGA, but all the clocking PLL and really high speed signals are taken care of allowing you even higher speeds like 1.5gb and 3gb using only 2-5 FPGA inputs per SDI channel. Same for HDMI, but the IP for that 1 costs big $.
The mentioned XAPP224 uses quadrature clock to obtain 4 sample points per bit. All clocks are equal to the bit rate, which is 270MHz, not 540MHz - that is unfortunately way out of range of a cheap FPGA such as the Cyclone IV E is. (I think the maximum theoretical limit is about 400MHz according to the databook, for the cheap C8 speed grade)
The FPGA I have only has two PLLs available. As far as I understand, each of the PLL has only up to 5 outputs.
I could probably use just one of the PLLs to produce 270MHz SDI clock, both polarities of the in-phase and both polarities of the 90° shifted clock. Hopefully...
Iknow about those external serdes ICs. But they are either hell obsolete, or cost utter bullshit, like 5times or more the price of the FPGA itself (I have already tried, there is alson the other SDI thread, where I have asked about this). Also, I do not need 3gpbs serdes for 270mbps job. And 270mbps only serdes ICs are no longer made.
How many inputs do you need? I typically would have used 2 with 2 PLLs. Feeding those 2 inputs, I would have an 8x2, 16x3 or 16x4 SDI crossbar switch IC which allowed 1 channel working while selecting an alternate channel, doing my clean swap, then using the alternate channel to select the next channel to swap to. This means only 2 PLLs were required for PLL locking to a source input signal.
Also, 270mb is slow, it you want to play dirty, you could use 2 adjacent FPGA IOs with an inductor and 75v zener or tuning diode with resistor and cap to make a crude 270MHz or 135MHz PLL oscillator. You would need to assign 'Fast output' and 'Fast input' registers for those IO with the serial input to keep consistent timing between compiler builds. I must be fair here and say I've been successful at 54 Mhz 20 years ago and the first generation FPGAs. 270Mhz would be an exercise in experimentation, but you can have each SDI input utilize 3 FPGA IOs and have true dedicated PLL clocks for each one.
-
For this learning toy project, I don't think I actually need more than 3 inputs (2x SDI in, 1x CVBS in).
I am starting to like quite some the idea described in the Xilinx XAPP224, oversampling the input with multiphase clock. Requires no input-dedicated PLL, apart from one to create a common system clock, used then to deserialize any number of inputs.
I will either way put one external loopfilter+VCO on the PCB. No dirty tricks with FPGA pins and inductors, MAX2607 is a cheap VCO (https://datasheets.maximintegrated.com/en/ds/MAX2605-MAX2609.pdf) and a pretty clean source too. (<$1 from the "usual sources").
-
Updated block diagram and a bit of first sketch how the board layout may look like. I like to think about it a lot before I start working on these. Power supplies will occupy the right hand side space on the board.
[attachimg=1]
[attachimg=2]
-
I will either way put one external loopfilter+VCO on the PCB. No dirty tricks with FPGA pins and inductors, MAX2607 is a cheap VCO (https://datasheets.maximintegrated.com/en/ds/MAX2605-MAX2609.pdf) and a pretty clean source too. (<$1 from the "usual sources").
LOL, the MAX2607's block diagram is basically what you would have been creating...
-
TVP5150 does not seem obsolete: http://www.ti.com/lit/ds/symlink/tvp5150am1.pdf (http://www.ti.com/lit/ds/symlink/tvp5150am1.pdf)
Can be sourced from the usual sources from the east for less than $1, unlike the ADV7280, which costs more than I have payed for the FPGA. But sure, the ADV7280 has 4 analog inputs and likely a better ADC, and can do YPbPr, which may be beneficial for some cases.
AFAIK, the AM version is a long-term availability version. Probably exactly the same but only available at much higher prices through regular sources. But if you don't mind going through chinese suppliers it doesn't really matter. Not my cup of tea though. I actually bought some chines 5150 modules and I could never get them to lock on the incoming signal.
-
I will either way put one external loopfilter+VCO on the PCB. No dirty tricks with FPGA pins and inductors, MAX2607 is a cheap VCO (https://datasheets.maximintegrated.com/en/ds/MAX2605-MAX2609.pdf) and a pretty clean source too. (<$1 from the "usual sources").
LOL, the MAX2607's block diagram is basically what you would have been creating...
Sure, it is called a VCO. ;D
TVP5150 does not seem obsolete: http://www.ti.com/lit/ds/symlink/tvp5150am1.pdf (http://www.ti.com/lit/ds/symlink/tvp5150am1.pdf)
Can be sourced from the usual sources from the east for less than $1, unlike the ADV7280, which costs more than I have payed for the FPGA. But sure, the ADV7280 has 4 analog inputs and likely a better ADC, and can do YPbPr, which may be beneficial for some cases.
AFAIK, the AM version is a long-term availability version. Probably exactly the same but only available at much higher prices through regular sources. But if you don't mind going through chinese suppliers it doesn't really matter. Not my cup of tea though. I actually bought some chines 5150 modules and I could never get them to lock on the incoming signal.
Well, Chinese suppliers or not... as a low income hobbyist, there is not much choice. It is either the BOM being <$20 total, or becoming more than $200 otherwise.
Could not lock onto incoming signal... huh. TVP5150 ain't the simplest IC to work with from the software side. You sure it was correctly programmed?
I currently have no way to test the TVP5150 I got, but should not be difficult to do, to see at least the sync outputs toggling at the correct frequency.
In the end, even if I should buy TVP5150 from Mouser, it is still almost half the price of ADV7280. :-//
-
Could not lock onto incoming signal... huh. TVP5150 ain't the simplest IC to work with from the software side. You sure it was correctly programmed?
Off course not :-DD I programmed it best I could, chose the easiest possible configuration and it would not lock. Problem with programming? Bad chinese chip? Who knows. Rather than to waste time on it (or rather to waste my clients money) I switched to an actual AD dev kit and got it up and running in no time.
-
Used the TVP5150 and ADV7178 in a PAL to NTSC converter many years ago and never had any problems. Data in and out of the FPGA was 8-bit 4.2.2 YCbCr BT656. The only minor issue was the TVP5150 14.31818 MHz crystal being slightly off giving rise to some incorrect color encoding, a slight tweak to the crystal loading caps fixed the problem. TVP5150 is a nice chip and it's a shame it's not recomended for new design. EDIT: First iteration used the ADV7182 decoder, it didn't work and ran very hot, never found out why.
-
Could not lock onto incoming signal... huh. TVP5150 ain't the simplest IC to work with from the software side. You sure it was correctly programmed?
Off course not :-DD I programmed it best I could, chose the easiest possible configuration and it would not lock. Problem with programming? Bad chinese chip? Who knows. Rather than to waste time on it (or rather to waste my clients money) I switched to an actual AD dev kit and got it up and running in no time.
If you work for someone else's money, than it is a quite different story. But not the case here.
I'll probably make my own TVP5150 breakout board to see and test the chips I got. At least I can test my software library and see if it works.
-
So for the giggles and what not, I have slapped together this small bastard to test a couple of the TVP5150 chips I got, whether I can make them lock onto video signal. I will have it manufactured somewhere in the January, with some other stuff.
As simple as it can get:
[attach=1]
Now my lab is starting to lack a couple of things: A decent oscilloscope (500+ MHz BW), video signal (test pattern) generator and a BERT (I may just cobble one up later, PRBS generator would be a nice project to do with an FPGA). Seems some shopping may be ahead. Oscilloscope first, I am starting to hate the Hantek shite, and the old Agilent 3062A is good for watching the CVBS video at best. ;D
-
Looksie what we got! Finally. (I made the mistake of ordering via snail mail). I am looking forward to trying this one out.
[attachimg=1]
-
The board look's great :-+
Quite some years ago I got my hands on the Bitec Video Dev Kit cycloneIII 3C120 it did use the TVP5140 chip and it did work fine.
Here you can find the Bitec documentation and source files which might help you
https://bitec-dsp.com/product/cyclone-iii-video-development-kit/ (https://bitec-dsp.com/product/cyclone-iii-video-development-kit/)
-
The mentioned XAPP224 uses quadrature clock to obtain 4 sample points per bit. All clocks are equal to the bit rate, which is 270MHz, not 540MHz - that is unfortunately way out of range of a cheap FPGA such as the Cyclone IV E is. (I think the maximum theoretical limit is about 400MHz according to the databook, for the cheap C8 speed grade)
I've used SDI received on Cyclone II (yes, that's 2), which used 337.5MHz clock with phase shift for bit decoding. It had some specific constrains, i.e. the sampling flip-flops had to be physically located next to the input pins. See Appendix A-8 here: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_sdi.pdf (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_sdi.pdf)
For clock generation, it was popular to use Genlock components from company Gennum, but I think they were later acquired by Semtech.
P.S. I worked on this 8-9 years ago... Might be crazy outdated.
-
Well, even the Cyclone IV I'd like to use is crazy outdated, but I don't give a rats ass. As long as it is a cheap suitable alternative with good availability, I'll try. I just don't see a reason to justify the overpriced new devices.
I am not sure, but aren't those "megacore" functions only available for a subscription fee? Obviously, I'm a hobbyist in this case, not a corporate willing to pay nonsense.
Can anyone of the TVP5150 aficionados give a hint as what is needed as a minimum configuration of the TVP5150 to chew on some video input? It's been quite some time since I have studied the datasheet thoroughly and tried to understand it. I am looking forward to soldering the board today and start putting down some code for it.
Thank you
-
Board soldered. I'll test it probably tomorrow, or in the near days.
-
I'm an idiot. FUuuuuuuuuuuuuuuuuuuu!!
I forgot to make a breakout for the IOVDD separately and incorrectly named the 1V8 bus as 3V3. Dammit! Fortunately a fix is simple enough.
[attachimg=1]
(.. and exactly this is why I tend to test stuff part by part, block by block and only then I build complex circuits on a single PCB).
-
I am not sure, but aren't those "megacore" functions only available for a subscription fee? Obviously, I'm a hobbyist in this case, not a corporate willing to pay nonsense.
Yes that's correct, and the VIP (VideoIP) are very expensive, you can have a test license for 1 month but 1 time per PC.
Alternative is to buy a dev board with one of the bigger non "Free" Quartus supported devices from Altera / Intel, some of them have a 1 year full license with the VIP which are way cheaper than a normal license for a year.
-
Okay, no change of game plan then. I will make my own set of IPs.
-
I am not sure, but aren't those "megacore" functions only available for a subscription fee? Obviously, I'm a hobbyist in this case, not a corporate willing to pay nonsense.
Yes that's correct, and the VIP (VideoIP) are very expensive, you can have a test license for 1 month but 1 time per PC.
Alternative is to buy a dev board with one of the bigger non "Free" Quartus supported devices from Altera / Intel, some of them have a 1 year full license with the VIP which are way cheaper than a normal license for a year.
Fun fact: the SDI ancillary audio data extraction function on Altera core did not work correctly and support did not respond on that. I guess that core was made by some 3rd party and Altera support did not have details about it. I had two options: write my own core from scratch or decode/unlock/hack the existing one and fix the bug. The money was paid for the original code, so went with option #2 and succeeded. However, not recommended by any chance.
-
Good news everyone, I have bodged the board so the chip gets a correct supply voltage of 1V8 and voila! After a bit of I2C wrestling, we have R.BT.656 data output, even with dedicated VS and HS signals at the correct timings.
The IC used in this experiment is one of a bunch I got from Aliexpress dirt cheap. (I mean like $1 a piece or less). They seem to be the TVP5150AM1 newer version, according to the marking.
Unfortunately, I do not have anything I could plug the video data directly into, that will have to wait for some other FPGA work. :-/
Here's the bodged pcb with added voltage regulator, for fun and giggles.
-
Nice you got the board running, but don't you have any FPGA board at all to play with?
Way back I had the BT656 to drive a small OLED board via a FPGA by just using some of the BRAM as timing buffer between input / output data
-
I haven't touched FPGAs so far, so no boards available, just a bunch of unsoldered Cyclone IV in LQFP144 are laying here.
I have only worked with a few CPLDs in the past, simple stuff, I have only couple boards with Altera MAX II CPLD. But I don't think I could do much with such a CPLD regarding the video signal. Probably just try writing a state machine for decoding the SAV/EAV and extracting the H, V and F flags on some IO pins and probably ad something like a line counter.
I have ordered a development board with Cyclone IV E device from China, but due to the unfortunate situation in China now, the board will not probably arrive any time soon. I'd probably slap something together myself faster.
What I would currently like to work on, is to make a complementary PCB with a video DAC (encoder). Some of you may have already notice I have yet again spammed the forum asking for an BT.656 to CVBS encoder IC suggestion.
I will probably make a re-spin of the TVP5150 board to have the mistake fixed and will make some video encoder board, that can take the BT.656 data and spit out the PAL/NTSC CVBS back. Probably will use something small and simple like ADV739x (datasheet) (https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7390_7391_7392_7393.pdf).
Having a video ADC and DAC will be a good starting point, any of these two could be easily wired to any FPGA kit my hands will get onto.
-
It seems I've been way too hyperactive last days. Here you have a board for the ADV7391 video encoder/DAC.
The layout is not what I am proud of, there are just too many compromises. But you can't expect a pretty layout on 2 layer board with a part designed for 4 layer boards (and 0402 or 0201 component size). Either way I don't think it is that bad it could not work, I think it will work well enough, sure at least with SD resolution output, which is what I will mostly be working with now.
-
Hi! Little bit update, something bit more positive during the 'rona thing: PCBs arrived, soldered, I2C comm tested - successfully - to my all surprise.
Well, there was a bit of an ouch! moment during the first power up. The board consumed 47mA uninitialized, just after applied power. I have noticed, most of the current has gone through one of the DAC loading resistors. 2.6V was on one of the outputs. So I have panicked a bit, started to measure all around, poke my meter everywhere I could - found nothing. Suspecting a dead IC or poor soldering of the LFCSP package, I desoldered the IC just to see the soldering was perfect, no cold solder joints on any pins. So I have soldered another chip, while making sure wearing a poker face (look at the cost of the ADV7391. Ouch too!).
New chip soldered, same behavior. That got me curious. Grabbed an MCU kit, wired the I2C, asked for the content of the first register I came across - device responded on correct I2C address, returned the correct default value of that register. Then checked another few registers - all correct values.
I have noticed, that 47mA are still consumed even when the ADV7391 is held RESET, the DAC1 still spews maximum output voltage. Then I have examined the content of the "0x00 power status register". Sure enough, default is 0x12, DAC1 enabled. So I have disabled the DAC1. Now zero volts on all outputs, little current consumption.
WTF are they smoking and why would it put full output blast as a default, even when held reset, is beyond me. Sure, I do not provide any PCLK to the video interface, but this is strange behavior anyway.
Once I read through all those 100 or more registers and configure the mandatory of them, I will feed in some video data and test if it actually works.
-
Nice work, yes the great test will be to hook it up to your decoder board and see signal loop through, and then via a FPGA 1:1 for starting :)
-
Well, sure, that would be a success! However currently it seems to be more or less a nightmare.
I have found the ADV7391 has a builtin black and colorbar generator. So, trying the color bars - we have some major issues with signal purity. Something is injecting awful noise to the video output.
Looking at the output waveform using an osmelloscope, there are numerous places per line where quite substantial sharp edges occur during the active video.
Looking at a video monitor, looks like below. Positions of the occuring garbage is well correlated to the garbage on the screen.
Not any clue what this may be causing. Power supply should be solid and at specified voltages. I am just feeding in a 27 MHz reference clock (generated by the TVP5150 module).
It seems there may be an issue with the PLL in the ADV7391. If I gently touch the loop filter components, I can clearly influence the garbage injected to the output.
I admit the layout is not the best and it is just a 2 layer board. Even 4layers would not help much, as the datasheet suggested layout procedure is (tl;dr) just to put everything as close as possible to the chip. But for fucked snakes that is simply not possible, unless using 0201 components or what. The layout with the three loop filter components circled is also below. I could not come up with any better than this. All power supply pins are decoupled separately, using a 100n+4u7, with a ~100ohm ferrite bead in series.
//EDIT: Well, it may be a power supply issue after all? Placing a 47 mike electrolytic cap at random places has significant effects on the garbage production.
-
I am starting to hate this piece'o'crap IC. Looking at the EVAL board ... I have even tighter layout in places (for example the loop filter). I have the critical decoupling even on the same side as the IC - they have placed all decoupling on the bottom side, through vias.
Sure, I have not used the crazy capacitor combos of like "100pF 1nF 10nF 100nF 10uF" all in parallel - I've been taught that this may be even worse than a single or two in parallel.
Also, seems the board radiates like crazy somewhere above 80MHz. Likely the PLL output frequency. Looking at the EMC filtering components deployed at the EVAL board assures me this IC in fact is pure evil to use. :box:
I have played a bit with the ferrite beads, even replaced them with shorts. The garbage just changed and moved around.
I better find a different IC, that doesn't require black magic to work reliably. There are many things time can be better spent on than tweaking this thing to no end.
-
We are successfully using this encoder in automotive designs. Does the color bar generate good output on your screen using the same cables? I'd suspect an issue with impedance or cable length here as well...
-
Although I have used a 50ohm BNC cable (was the first to reach), I seriously doubt it has any kind of an effect whatsoever, with the length of a meter (~3ft). But sure, I can swap it for 75ohm one. (Seriously doubt anything will change).
The crap comes from the board itself, not from the cable. Even probing the boards output with an osmelloscope shows the same garbage spikes throughout the video line - corresponding to what the video monitor shows.
If you could look at my board please and tell whats that much wrong in there - many thanks! Layout is above, schematic attached below.
Currently I am either overlooking some dumb mistake, or I don't know what.
Note to the schematic:
Output low pass filters not soldered (L4=L5=L6 = 0ohm), R2 is 180 ohm instead of 170. (also quite doubt it makes the difference).
Now I have even tried to solder the loop filter even tighter together - nothing has changed. So it seems, it is not a problem with it.
The 1V8 LDO is cheap garbage, sure, but I think well suited for the task. The load on it should be quite minimal. PLL VDD draws about 4mA, the logic supply VDD should draw about 33mA (one DAC enabled only). The regulated voltage is 1.813V. Also within spec. VDDA and VDDIO are at 2.9V, which is also within spec. Using an external supply to put stiff 3V3 there helps nothing, no change.
Or is there anything wrong with the configuration? Here are all registers I have written the value into:
register, value, comment
0x00, 0x10, DAC1 enabled, PLL on
0x01, 0x00, SD mode only
0x02, 0x20, YPrPb output mode
0x80, 0x11, SSAF luma filter, PAL
0x82, 0xCB, SSAF filter enable, CVBS output select
0x84, 0x40, Color bar output enable
0x87, 0x20, NTSC/PAL autodetect
//Cable already changed to 75ohm 1m piece, no change, as expected).//
-
Awww! Found out the PLL does not need to be turned on. So I've switched it off (0x80 <= 0x12) and voila, we have a crystal clear color bars.
So it is the PLL after all?
-
Had a look at the sample design in the data sheet - The example decoupling is 0.1uF + 0.01uF on most rails, and 0.1uF + 0.01uF + 1.0uF on the 3V3 rail.
You have mostly 4.7uF + 0.1uF - maybe that is where the issue is coming from? Is it worth trying replacing a 4.7uF with a 0.01uF on PVDD that supplies the PLL?
(Decoupling isn't my strong point... more interested in hearing the reason for parts selection)
Only thinking this because I've seen so stuff on Twitter about noise on the PLL supplies causing all sorts of weirdness.
-
Well... as far as I know, a ceramic SMD cap can not have much inductance past its physical length.
This random internet image seems to confirm. If the inductance would be different per capacitance value, the right side of the plot above the resonant point would not agree in the steepens. Yet they all agree, so the should have about the same inductance:
(https://i.stack.imgur.com/zmMpK.gif)
I have used 4u7 because it is the largest value in 0603 I have. (I have even tried soldering another one on top to get more capacitance in there, but no luck).
I have even hacked the board, making the loop filter even tighter. Even tried adding 10nF to the PLLVDD as close as the bodge allowed. No substantial improvement. The crap just moves around, but will not disappear.
I have even moved the 2n2 "COMP" cap for the DAC to this new position, as below. No difference whatsoever. Crap still present in signal.
//EDIT: Forgot the image.
-
register, value, comment
0x00, 0x10, DAC1 enabled, PLL on
0x01, 0x00, SD mode only
0x02, 0x20, YPrPb output mode
0x80, 0x11, SSAF luma filter, PAL
0x82, 0xCB, SSAF filter enable, CVBS output select
0x84, 0x40, Color bar output enable
0x87, 0x20, NTSC/PAL autodetect
Awww! Found out the PLL does not need to be turned on. So I've switched it off (0x80 <= 0x12) and voila, we have a crystal clear color bars.
Great to hear you have to work :)
I think you need to be absolutely sure it's the correct registers you set in the pdf https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7390_7391_7392_7393.pdf (https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7390_7391_7392_7393.pdf)
There are some differences to what you refer to 0x80 <= 0x12 which I guess must be 0x00<= 0x12 means DAC1 on and PLL off ( This control allows the internal PLL
circuit to be powered down and the oversampling to be switched off x16)
So I think the PLL still runs but not as 16x
In the pdf there are on page 92 and forward examples what registers should be set for what depending what you what to get out
-
Sure, I meant 0x00 <= 0x12, not 0x80.
I did not use these tables from the datasheet, I downloaded some software packages for the eval board and reverse engineered some configuration scripts for the board.
So, the most relevant table for me is Table 82. So lets compare, what there is different:
Table 82 wants this:
[attachimg=1]
So, first difference, is that I do not do a software reset. Is it any different from a HW reset? But I can add it there.
Second difference is that they enable all DACs. I do not want/need that. Likely not a problem. They leave PLL running!
Third difference is register 0x82. They want 0xC3, I have 0xCB. I have enabled the pedestal. As they do on their eval board. (But PAL should not use pedestal? Not sure, still it wouldn't produce the crap I am seeing, as the pedestal stays put even with PLL OFF, where it works just fine).
Fourth difference: I enable color bars in 0x84 register.
Fifth difference: I enable PAL/NTSC autodetect in 0x87. As observed from the eval board scripts. I still don't see a problem.
Sixth difference: I forgot to set the subcarrier frequency registers.
That of course may make some difference.
I have also just noticed, the scaler I run the video through to my monitor reports the video is NTSC, even though I should get PAL.
So lets fix the subcarrier frequency first. :-/O
//EDIT: Subcarrier fixed, standard autodetect removed. Now it produces PAL/50Hz output. Crap still present in the image. So we are still where we were before. Crap in image output, only NTSC got fixed to the proper PAL.
-
Finally I have saved a screen from the scope, as to what the signal integrity problem looks like. There are these awful spikes, mostly concentrated to the places corresponding to the crap seen on the video monitor.
-
Yep table 82 was the one I would go for as well ...
For only 1 DAC have 0x00 <=0x10 instead of 0x1C you see both in the table
I would do the soft reset as well
Regarding to the noise, you mention you get the 27Mhz clk from the other board, om page 5 you have INPUT CLOCK SPECIFICATIONS
It could be worth to check with a scope if you are within the spec (levels)
VDD = 1.71 V to 1.89 V, PVDD = 1.71 V to 1.89 V, VAA = 2.6 V to 3.465 V, VDD_IO = 1.71 V to 3.63 V
If you overdrive the PLL input it might do something wrong to the PLL
The TVP5150 are running from a 14.318 xtal between Xtal1 and Xtal2 pin , which pin do you have the 27Mhz out on?
-
I use the 27MHz CLK output from the R.BT.656 output data bus. it provides a pretty precise 27.0000 MHz according to the counter in my scope.
Not even close to sure, how the TVP5150 manages to obtain 27MHz from those 14.31818 MHz crystal. There is 27 MHz present even if there is no video signal present to the TVP5150.
The only thing I could test is to grab a 27 MHz crystal and make a standalone clean oscillator to feed the ADV7391. To rule out the 27MHz clock from the TVP5150 decoder may be full of crap (it does not seem so, from looking at the clock on a scope).
What is interesting, is that modifying the decoupling on the 1V8 rail on the PCB has an effect on the crap spikes. But it always just moves around, instead of being suppressed.
I will try a few more things with the 1V8 regulator and decoupling and then will look for ways to obtain a clean 27 MHz clock for something.
Also I bring to mind, that when the PLL in ADV7391 is switched OFF (no oversampling), the output video signal is crystal clear, with no glitches.
-
Awww we are getting somewhere!
I have left the on board LDO to power just the PLL. The VDD logic is supplied from an external lab supply. IMAGE IS CLEAR! Even with the PLL enabled. So what the hell is going on there? :-// :scared:
-
Could you post your acual schematic?
-
Could you post your acual schematic?
I have already done that! Including the layout. See post #55 and #52 above.
I can only add, that originally I have used a ferrite beads from TDK, 1.5k @100MHz (MMZ1608Y152BTA00), now I have switched to Tayo Yuden 600R @100MHz (FBMH1608HM601), as these should be better at suppressing higher frequency crap. But the change did not help.
Now there is ferrite bead only on the PLL (the 600R Tayo Yuden) and on IOVDD (there may be even the 1.5kR TDK? not sure). The DAC is supplied straight from 3V, no ferrite bead. The 1V8 VDD is currently also no ferrite bead, straight from a lab PSU. Sorry for this mess, but I have tried to trace the issue by swapping a lot of components and toying with the decoupling/filtering.
//EDIT: I think the next step will be to return the board to its original form (so it will be precisely as the schematic), remove all bodges, except the external logic VDD 1V8 supply. I am interested to see as what it will do.
-
Sorry miseed the schematic. ::)
If you look at this eval board http://media.digikey.com/PDF/Data%20Sheets/Analog%20Devices%20PDFs/ADV739x_EvalBrd_RevB.pdf (http://media.digikey.com/PDF/Data%20Sheets/Analog%20Devices%20PDFs/ADV739x_EvalBrd_RevB.pdf)
Page 32 + 36 then you will see that they have
Analog supply as 3.3V
PLL supply as 1.8V
Digital supply as 1.8V (you have 3.3V)
So try to run the VDDIO from the 1.8v reg but you will properly need to separate it to a different regulator
btw they also have the PCB layout
-
So the board is in its original shape, all components the value exactly as specified in the schematic, all ferrite beads TDK 1.5k @100MHz (MMZ1608Y152BTA00). All parts soldered at their respective footprints, bodges and hacks removed, except the external 1V8 supply for the VDD pins. (external suppply injected at the place of L2 on the board, L2 not used, unpopulated)
It seems to work, reliably even in this original state (except the external VDD supply).
So what the hell is wrong when both PVDD and VDD is supplied from the same LDO? VDD consumes about 36mA which is in accordance with the datasheet. No excessive draw.
Here is the current layout and current schematic, for clarity added again.
//Why would I run VDDIO from 1V8 if I want to interface with 3V3 logic? The recommended range for VDDIO is from 1.71 to 3.63V. I a within spec.
To be exact, as measured on the board:
VDDIO = 2.886V
PVDD = 1.811V (from the onboard LDO)
VDD = 1.767V (from external lab PSU)
VAA = 2.867V
That is well within the spec.
-
Hard to tell what is wrong, but I guess when the PLL runs it makes noise on the PVDD and that's why the official eval board use 2 LDO's for the same voltage.
I haven't found any specific in the ADV7391 pdf telling it has to be separated but since there are 2 individual pins on the chip there must a reason, just add an extra LDO on the board :-[
-
on page 18 it says ABSOLUTE MAXIMUM RATINGS:
VAA to AGND −0.3 V to +3.9 V
VDD to DGND −0.3 V to +2.3 V <=Here you can't have 3v3
PVDD to PGND −0.3 V to +2.3 V
VDD_IO to GND_IO −0.3 V to +3.9 V <= here it should be fine if you want to have io on 3V3
Btw your 3.3V are pretty low 2.9V
-
I haven't said there are 3V on VDD. That was you :P
Well, I power the setup from STM32 kit, that operates from a 3.0V nominally. The 2.9V is the result of the crap arduino wires, having some voltage drop across them.
Would be interested to know, why one can't do around with a single LDO. If the IC is so much noise susceptible, then I'd simply say it is a rather poor IC design. >:( I understand, when a multi GHz synthesizer with many tens of MHz per V tuning slope VCO may have an issue with noisy PSU, but this thing?
-
I take that the 3.3V was my assumption ::)
There is a engineer zone here https://ez.analog.com/video/f/q-a/5588/adv7391-vddio-question (https://ez.analog.com/video/f/q-a/5588/adv7391-vddio-question)
One guy are discussing the VDDIO and the answer back are:
No this is not an error in the datasheet. VDD_IO can be operated at either 1V8 or 3V3. When operating at 3V3, the voltage limits are between 2.97V to 3.63V and when operating at 1V8 the voltage limits are between 1.71V to 1.89V. This is why the max/min ratings in the datasheet for this supply have the wide margin. The caveat with running the part @ 1V8 as opposed to 3V3 is that the I2C, HS and VS signalling all need to be operated at 1V8 levels. See P8 of the ADV7391 datasheet for more information regarding this.
So if you supply is 2.9V then the data level might be a little less and you might have issues with correct function... just saying
Also it might be possible to ask at that webpage to get an answer for the need of 2 LDO's
-
That is some interesting bullshit going on then. They specify the VDDIO range from 1.71 to 3.63V and the tell you "ah, you can't use 2.5V", but it is not a datasheet error? :bullshit:
But back to my problem - the exact voltage on the VDDIO (and VAA, I have both tied to the same "3V3" input) has zero effect on the crap generated.
It seems either the IC is extremely susceptible to noise on PVDD (which, again, leads me to believe the PLL has sub-par design), or that the LDO I have used is not up to the task.
Sure, the Torex XC6206 is cheap crap, but this IC is the first one having problems with it.
What LDO should one use then? Another $5 job for a $10 IC? For this price they could even include suitable LDO for the PLL themselves.
I am not sure if asking would get us anywhere, or what should I exactly ask for. The datashet says quote: "Power Supplies:
It is recommended that a separate regulated supply be provided for each power domain (VAA, VDD, VDD_IO, and PVDD)." So in fact I should have used 4 separate LDO. Fück dich!
I have tried a while back to filter the VDD domain using a series connected small 4.7uH, ferrite bead, then placed a 220uF elko, 10uF MLLCC + 100nF parallel. The shit still spews crap on the output.
Now you tell me, is the IC poorly designed or what, if this is not enough, to get the crap out?
As a last measure, exhausted and defeated by a a rather poorly designed ADI product, I will try to bodge separate LDO on the board.
-
I have bodged in second LDO (the same cheap XC6206), found a good spot for it on the board. Fortunately, this hack works a charm. I take this lesson with a grain of salt. Due to really not liking the idea of multiple LDOs and due to the fact I am not sure what was the problem - apart from knowing how to
solve go around it.
Onto the next quest: Wiring the TVP5150 data output to the ADV7391 data input. :popcorn:
-
Great 8)
Just found another power supplies discussion, here they say you can use 2 LDO's instead of 4 LDO's if you have ferrite beads separating the various power pins refer to figure 93 and 94 but I guess you wont use more time on that
https://ez.analog.com/video/f/q-a/10808/adv7391-power-supplies/28842#28842 (https://ez.analog.com/video/f/q-a/10808/adv7391-power-supplies/28842#28842)
Yes, Wiring the TVP5150 data output to the ADV7391 data input is next big step ... like a to get led flashing
I guess you still have no FPGA up running?
-
To quote the relevant part from the link:
These sources can be generated by 2 different regulators. Figure 94 has ferrite beads separating the various power pins to isolate AC coupling between the internal sections of the chip. You can use 4 LDOs or regulators but 2 will suffice as long as you have the ferrite isolation.
Unfortunately their suggestion of using just 2 LDOs is pretty much incorrect, as far as my observations go. We can clearly call some :bullshit: on that.
I would be glad to hear where does the difference come from, between using extreme measures in RFI filtering (4.7uH, 1.5k bead, 220uF+10uF+100nF) and a cheap shit LDO, that has what, 20dB of rejection at 10kHz to isolate the noise? ???
No, I already have both FPGA kits I have ordered! They came in few days ago. That was the motivating force behind soldering and testing the ADV7391 board.
One kit is a "full featured" one, for toying around with LEDs, the obligatory VGA and stuff with just little spare IO, the other one is just the FPGA, bunch of LDOs and a configuration FLASH. All IOs free (except a button I am not sure what it does and a couple LEDs).
I have had a dinner, so no we move to the next quest, please standby. :-/O :popcorn:
-
I am quickly becoming confident in a few things:
a) i HATE those arduino jumper wires. Evil crap! Years ago, I have crimped those myself. Then stared buying them from china - they were good enough. Now from the last bunch, just one third of them works, yet only up to maximum of one pin insertion! Then the pin looses springiness and electrical contact (if it had any to start with).
b) without a fast enough logic analyzer, I am fuckered. And the 2 channel scope at home is not of much help either.
So, after solving a) and throwing all of the junk to the bin where it belongs and using my own crimped jumpers, I have finally managed to connect the decoder and encoder together, all signal lines.
But regarding b) I just don't know what is happening there, apart from "some bits are toggling more and some are less". :palm:
After dicking aroung with the oscilloscope, I am quite confident that the TVP5150 works correctly and provides SAV/EAV sync. It is even that kind, that it continues to send SAV/EAV even on video loss (or no input video). This has allowed me to kind of see on the scope, what is going on. I can definitely tell, it sends 0xFF, 0x00, 0x00 and then the magic XY byte.
The XY byte contains:
MSB LSB
7 6 5 4 3 2 1 0
1 F V H P3 P2 P1 P0
From the scope I can definitely tell, b7 is always 1 as it should be. F gets toggled, V gets there occasionally and H bit (SAV/EAV) is correct and the whole SAV/EAV sequences seem to be places sensibly.
So the BT.656 video source works correctly, but the ADV7391 is like zero fucks given. All it does is it just keeps producing blank lines with colorburst, that are not aligned with EAV/SAV and does not generate any vertical blanking/sync. (it does this even with just the clock present). It simply ignores the input data. WTF!
-
Cheap jump wires / headers and breadboard etc are often source to malfunction
I prefer to use real header plugs and solder it to a piece of veroboard and then have normal wire soldered directly from a to b.
I did a quick look in a old TVP5154 project code and you will need to the the correct registers set to get the right data out, could you show you registers settings?
I do see I used but I recall that it was special due to I had some limitation in the TTL interface on OLED panel connected to TVP5154
0x00 <= 0x00 Video Input Source
0x03 <= 0x09 Miscellaneous Control Register, YUV output enable, Clock output enable
0x04 <= 0xC0 Autoswitch Mask, video pal, ntsc autoswitch
0x13 <= 0x80 ;-avid cropping-
I saw in another discussion on TVP5150 that one guy use
Miscellaneous Controls Register(0x03) : 0xAF
Auto-switch Mask Register(0x04) : 0xC0;
Outputs and data rates select(0x0D) : 0x40 ;
Configuration Shared Pins Register(0x0F) : 0x02 ;
Do you have the I2C so you can read write on the fly?
You can then do some reading to see that it actually are locked to the input
Status Register #1 Address 88 like flags for: Field rate, Lost lock, Color subcarrier lock, Vertical sync Horizontal sync
Edit: Ti writes:
The only required register change is to enable the clock and data outputs. These are disabled by default to allow bus sharing with additional devices.
-
I will probably use proper IDC headers later, currently I do not suspect a bad connection at all. I probe all signals on the ADV7391 board, nothing is missing and the signal integrity does not seem to be bad at all.
The only thing I write to the TVP5150 is the Misc Register (0x03): 0x0D. Should be all that is needed. It just enables the clock output, data and the aux IO pins (HSYNC, VSYNC, AVID, PALI, ...) so I can trigger from them the oscilloscope.
This simple config is straight from the datasheet example for "Output format: 8-bit ITU-RBT.656 with embedded syncs", where they want you to just write 0x09 to reg 0x03. I write 0xD insteadd so I have available the other HW outputs for triggering.
The TVP5150 works fine, I am almost certain.
I saw in another discussion on TVP5150 that one guy use
Miscellaneous Controls Register(0x03) : 0xAF - I do not need VBLK out, hence I have just 0x0D
Auto-switch Mask Register(0x04) : 0xC0 - he just enables all video modes (PAL-NM, NTSC4.43), I do not need that, now.
Outputs and data rates select(0x0D) : 0x40 - I need BT.656 encodind, hence 0x47, the default value. (0x40 is 4:2:2 with external sync)
Configuration Shared Pins Register(0x0F) : 0x02 - some additional pin conf I do not need
All I need to change from default is just to enable clock, data. That is to write 0x09 (or 0x0D) to Misc reg (0x03).
Can not read I2C on the fly, but that is not a problem to make happen.
Edit: Ti writes:
The only required register change is to enable the clock and data outputs. These are disabled by default to allow bus sharing with additional devices.
Sure, that is exactly what I do: Write 0x0D to Misc reg (0x03)
//EDIT: Reading the status register 0x88 now, it goes to 0x66 if I apply the B&W video from the camera - so it is okay as expected.
-
I think we do not have much options left.
TVP5150 seems to be just fine, ADV7391 is likely the troublemaker. What options we have left how to attack the situation:
a) look at ADV7391 and search for possible status registers to debug where the problem may be
b) make better wiring in between the TVP / ADV (though I do not suspect any problem there)
c) grab an FPGA kit and start working from there. Would for example help to make a SAV/EAV decoding machine to see whether all flags in the SAV/EAV are correctly transmitted. Should not be that hard beginner project.
d) Generate BT.656 stream within the FPGA, to test the ADV7391 with.
I can certainly make b) happen and try to look into a).
-
Sure, that is exactly what I do: Write 0x0D to Misc reg (0x03)
//EDIT: Reading the status register 0x88 now, it goes to 0x66 if I apply the B&W video from the camera - so it is okay as expected.
Perfect: Line alternating, 50Hz, Vertical sync is locked, Horizontal sync is locked, no color subcarrier
Does the levels (on the scope) at the data bus look nice within spec for the ADV7391 and the VDD_IO?
-
I think we do not have much options left.
TVP5150 seems to be just fine, ADV7391 is likely the troublemaker. What options we have left how to attack the situation:
a) look at ADV7391 and search for possible status registers to debug where the problem may be
b) make better wiring in between the TVP / ADV (though I do not suspect any problem there)
c) grab an FPGA kit and start working from there. Would for example help to make a SAV/EAV decoding machine to see whether all flags in the SAV/EAV are correctly transmitted. Should not be that hard beginner project.
d) Generate BT.656 stream within the FPGA, to test the ADV7391 with.
I can certainly make b) happen and try to look into a).
Sounds like you need to address all 4 items to get the full understanding / confidence
What FPGA board did you buy Intel or Xilinx? model?
-
Data seem to look almost too good for the style of wire in between the boards. See below. Blue trace is the bit 0, capturing either the SAV or EAV sequence (black video generated by the TVP5150 without video input). Yellow trace is a part of colorburst that just got in the way. Data voltage level seem absolutely fine for the supply voltage (2.9V). And if you think that is too low, I have tried overriding the 3.0V regulator with external 3.3V power supply - as expected it made no difference to the behavior.
ADV7391 still ignores input data, EAV/SAV is not correlated to whats happening on the output, the ADV7391 is just free running from the bus clock, generating black lines with color burst and no vertical sync (all lines are identical: just sync pulse + colorburst)
Regarding a) I see the ADV7391 has exactly zero status registers, that would report anything useful to debug the problem as far as I see.
Regarding b) Better wiring is under way, had to pause for a lunch. Now need to find some female pinheaders and ribbon cable.
Both kits I have are with Altera Cyclone IV, EP4CE6E22C8N (6k LE, 2 PLL, 270kbits RAM, 15 18bit multipliers) . Not bad and can be sourced from china for as low as $2 a piece - almost too good to be true. I have decided to go with Altera, because I have already in the past toyed with Altera CPLDs, especially MAX3000 and MAX II so I am a little bit used to the Quartus software. But never did anything useful past some blinkenlights.
-
On the connection from the TVP to the ADV do you have 2 wires for Hsync and Vsync connected further than just the data-bus and the clk?
In ADV fig 51 H & V sync are negative (on PVP they are positive) it must be possible to select this instead of the EAV/SAV so if that settings are wrong the ADV might think there are no signal coming in
Table 82 use the EAV/SAV
on page 65 you can see how to use HV sync by setting reg 0x8A [2:0]
//EDIT. I do also mostly work with Quartus :)
-
Found another board from AD using the ADV7391
https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/EVAL-ADV7282A.html?doc=EVAL-ADV7282AEBZ-UG-1174.pdf#eb-overview (https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/EVAL-ADV7282A.html?doc=EVAL-ADV7282AEBZ-UG-1174.pdf#eb-overview)
They do have a script to set all registers and they set the 0x88 <= 0x00 to enable 8 bit input ... it should be 00 on reset but it might be worth to try
Also 0x87 <= 0x20 PAL / NTSC autodetect
56 00 1C ; Power up DACs and PLL [Encoder writes begin]
56 01 00 ; Set Encoder to SD mode
56 80 10 ; SSAF Luma filter enabled, NTSC mode
56 82 C9 ; Step control on, pixel data valid, ped on, PbPr SSAF on, YPbPr out
56 87 20 ; PAL/NTSC autodetect mode enabled
56 88 00 ; 8 bit input enabled [Encoder Writes finished]
-
Well, I do not have HSYNC/VSYNC connected anywhere, as I think it is pointless, when using embedded sync (SAV/EAV).
But I also kind of suspect, the ADV is not configured properly for SAV/EAV. Otherwise why the fck is it ignoring the data or the SAV/EAV?
Reg 0x8A is by default 0x08 in value, meaning slave mode, timing mode 0 (which seems to be SAV/EAV), at least according to page 80 in the datasheet. That should be fine.
Quartus: Great! As will likely need a lot of help. ^-^ Currently no clue how to configure it for a n FPGA and never figured out how to make a VHDL testbench plus specify/check timing constraints in that piece of software. :-\
Also, I have made a more tidy wiring between the two boards. A piece of ribbon cable coldered in between pinheaders. So now all bus signals are alternated with GND - should make for even better signal integrity. Yet the thing still does not want to work.
Somehow, sometimes the ADV starts capturing the data from the bus and spitting something out. Mostly garbage. Video still not synchronized (EAV/SAV clearly in quite different place, than the output), still no correct vertical sync on the output.
See below.
-
How does the signal from the scope look on a TV screen?
-
I unfortunately do not have any physical TV with a CRT. I have resorted to using a professional video scaler (TVone C2-2350) to convert anything to a standard PC monitor. And with the video signal missing any Vsync, the scaler just tells me to fuck off with a "not valid" signal comment.
So it seems I have likely found out why it did not work. The IC has a dead or stuck bit2. Absolutely no clue as to why.
As a last weapon of choice, I have resorted to really test all inputs to the ADV, using reg 0x13, the data bus readback. I have gone bit by bit, all responded correctly, except b2. Stuck at logic 1.
It was not a soldering issue. I have seen clearly the pin is correctly soldered to the pad.
Then I swapped to the original IC, I've had on the board the first time, as I was scared it got fried due to the strange current draw and DAC1 at 2.6V. But this behavior is normal, that the IC just wastes power after (and during) reset.
The other IC can read all bits correctly, and after enabling the data bus on TVP5150, I got results immediately. It seems to be working.
Not a clue what might have happened to the b2. Manufacturing defect? I would not say that is probable. :)
One thing that pisses me of with the TVone scaler, is that a) it seems not to accept B&W video, needs colorburst to work (holysmokes, what an idiot...) and b) it is not very timing tolerant. As a freaking universal scaler, which boasts the functionality to convert anything to everything, but can't accept PAL video, that is off by 0.02%or 200ppm (holysmokes... |O )
It is evident, that when I feed the TVP5150 with a video from the B&W camera, the scaler just quits working, cause the camera is 0.02% out of spec, because it has garbage timebase inside.
Luckily, I have different scaler and can make a different PAL source using a second scaler. So I'll just do that in a moment to see where does that leave us.
//EDIT: From the scaler specsheet - the only thing I can find about frequency range.
CV/YC sub-carrier lock range: +/- 200Hz for NTSC Operation, +/- 250Hz for PAL Operation
The camera produces 27.0056 MHz clock, meaning the color subcarrier is likely 921 Hz off. Fuuuuck! Thats just retarded.
-
So I have swapped scalers around. Feeding my monitor from TVone C2-770 (an old boat anchor). Now the C2-2350 is repurposed to make me a reference video, from HDMI computer output.
I can verify, that with the encoded PAL signal bypassed from one scaler to the other, I get correct video on my monitor. So both scalers working, configured correctly for PAL/50Hz.
Now, when I plug in the video path my decoder-encoder contraption, I get video through, but...
We have some color encoding/decoding issue. Luminance seems to get through correctly, but chrominance is fuckered. I get some flashy colors. It seems as if the Cr and Cb got swapped every other field.
Switching the ADV to generate color bars produces stable color bars. So there still must be an issue on the data bus. TVP and ADV still can't talk to each other very successfully.
But what the hell may still be wrong?
The actual exact config is this:
TVP5150
0x03 <= 0x0D
ADV7391
0x17 <= 0x02
0x00 <= 0x10
0x01 <= 0x00
0x02 <= 0x20
0x80 <= 0x11
0x82 <= 0xC3
0x8C <= 0xCB
0x8D <= 0x8A
0x8E <= 0x09
0x8F <= 0x2A
//EDIT: TVP5150 reports status 0x6E, so color subcarrier is locked. Likely not a problem on that side.
-
Great, when I saw your scope image I was confident that there were some signal in it
Yeah most scalers and converters are pretty sensitive to out of timing signals
Could you post a image of the problem you see on the screen?
You said you feed a B/W camera aka no burst but still get info that burst are detected so it might send wrong color info.
Please test only with normal PAL signals with color in just to be sure it is not found as a Y/C signal
If the colors are swapped Cr Cb, can properly be coursed by by several reasons.
It can be the TVP receiving PAL but running as NTSC /Secam or a wrong PAL mode or the BT656 set to a wrong mode the same can be tre problem in the ADV
And as you say wrong subcarrier freq.
At least you have some progress, :-+
-
Incorrectly understood! BW camera now back in the drawer, PAL video source is now from a scaler, that is converting HDMI to CVBS. So I have a full color PAL signal, with required timing precision.
Not sure what could cause the flashy color. Please see video of the problem below:
https://www.youtube.com/watch?v=79U9kZ3VDSI (https://www.youtube.com/watch?v=79U9kZ3VDSI)
-
I would say the the decoder TVP does not lock to the bust comming in
TVP5150
0x03 <= 0x0D
0x04 <= 0xC0 Autoswitch Mask, video pal, ntsc autoswitch Try play with the values here
0x28 set the video standard could be worth to try them all
0x8C tells the status for the video standard detected
https://e2e.ti.com/support/data-converters/f/73/t/118315?Need-guidance-on-Register-settings-for-TVP5150 (https://e2e.ti.com/support/data-converters/f/73/t/118315?Need-guidance-on-Register-settings-for-TVP5150) kind of same problem
They talk about wrong clk edge and filter for the input
the sequence YCbCrYCbCr I don't see anywhere how to swap them on the TPE
but on the ADV you have YCbCr and YCrCb
0x01 set it to YCrCb
0x88 set it to YCbCr
but it might be typo in the pdf
-
0x8C is 0x83, which means autoswitch mode is active and that "PAL (B,D,G,H,I, N) ITU-RBT.601" is detected. Which seems okay.
0x04: If I unmask all formats (write 0xC0), the autoswitch still chooses and reports as above.
0x28: Only forcing PAL (BDGHIN) or "combination N" works, yet chromaticity is still not working.
Just an interesting observation: The colors do not flip in between fields, but it seems between lines. I managed to capture this, the color carrier amplitude is fluctuating, even when observing a still image. Wtf?
Huh, isn't the PAL colorburst supposed to reverse its polarity in between lines? Seems like a good clue where to look. Like if the decoder would ignore this and not be properly locked on the colorburst. :-//
Sure, no way to change YCbCr to YCrCb. I think it is a typo, the BT.601/656 shall be clear about the sequence of bytes.
//EDIT: Just found this: https://e2e.ti.com/support/data-converters/f/73/t/701610?TVP5150AM1-TVP5150AM1ZQC-problems-PAL-colors-blinking-
Will investigate into that.
//EDIT2: Crystal oscillator seems pretty stable. Only wet finger across the crystal pins can really kill it. Does not give a rats ass abotu connected probe on either pin. Even tried 100k parallel resistor - no change, still flashy colors.
-
Image flashes like this, this one going in between blue and green. Not expert on PAL signal, but doesn't it somehow correlate to the color subcarrier phase?
-
Seems to be many discussion when you search for TVP5150 color flicker
eg https://e2e.ti.com/support/data-converters/f/73/p/357945/1256934 (https://e2e.ti.com/support/data-converters/f/73/p/357945/1256934)
Do you use te TVP5150AM1?
Do you have a resistor on pin 27? The TVP5150AM1 needs a resistor on this pin at reset (see figure 6-1 in the tvp5150AM1 datasheet). This will stop the color shifting issue.
-
Yes, I think I have the newer AM1 version. Will investigate into that. I have pull-up on the INTREQ/GPCL/VBLK pin, as I have intended to use the IRQ functionality. But sure enough, it is not configured now.
So let's see what it does if I configure it to IRQ.
-
Okay, so I have modified the Misc reg 0x03 to 0x2D value to enable the IRQREQ/GPCL/VBLK pin.
Reg 0x0F then selects between the IRQ an GPCL/VBLK function, but is default at IRQ mode. So I did not modify it. Still just writing only the misc reg 0x03, now with the value above.
FUCK ME! It works now. Now tell me, what is the retarded problem, that it does not sync to color, when this pin is not enabled? Like WTF?!!!!!!
So many thanks to you for helping me troubleshoot these two devices and thanks for the mental support during this fight.
-
This is great NEWS :D
From the last link
If this pin is not set correctly then the internal color PLL DTO does not function hence color shifting occurs.
The external resistor configures the internal processor to use the internal DTO for color demodulation.
Yep a couple of crazy problems, but now you can check-mark items a) and b) and start working on c) and d) and the fun part with the FPGA and then later move toward the SDI which where it all started
-
Sure, but how does a color demodulator relate to a pin that either: Sends interrupt requests (IRQREQ), functions as a general purpose output (GPCL) or serves as vertical blanking output (VBLK)?
In all of these modes this pin is OUTPUT.
It seems to me that this is more like a bug in the TVP5150 design, or it serves other undocumented purpose (most likely... ::) )
I have found round the web, there are quite a lot undocumented registers in the TVP5150 as well. >:D
Yup, now that the ADV and TVP are working, we sure can proceed to the FPGA. I need to at least try to create a new project for it in the Quartus.
Here you have the whole lovely contraption in all its parade ;D
-
Next version of the board you need to to rework the ribboncable layout :)
I found a pdf regarding pin 27 ... you have to wait 30 sec to download(did not find a direct pdf)
https://pdfhall.com/queue/gpcl-pin-configuration-f4fpt_5b71d00a097c4772308b45fa.html (https://pdfhall.com/queue/gpcl-pin-configuration-f4fpt_5b71d00a097c4772308b45fa.html)
-
Downloaded straight away (no waiting), thanks for the file.
This is due to some sharing internal to the device of the registers that control the GPCL and the Color DTO.
There is more than likely some hidden functionality, they use likely for production testing of the IC. There is exactly zero reasons why a "color DTO" should have anything in common with a generic IO pin, completely unrelated to anything with color. Working for 5 years for a major semiconductor manufacturer as their tech support, I have experience quite some bit of this "customer hidden stuff". So not surprised by this at all, but at least, should be made such that is does not interfere in a normal device operation.
Because this way, I can argue that their TVP5150 configuration examples from the datasheet are in fact incorrect, as they do not handle the damn GPCL pin appropriately!
5.1Example
15.1.1 Assumptions
Device: TVP5150AM1 Input connector: Composite (AIP1A)
Video format: NTSC-M, PAL (B,G,H,I), or SECAM
Output format: 8-bit ITU BT.656 with embedded syncs
5.1.2 Recommended Settings
Recommended I2Cwrites: For this setup, only one write is required. All other registers are setup by default.
I2C register address 03h = Miscellaneous controls register address
I2C data 09h = Enables YCbCr output and the clock output
But obviously, this is NOT enough. In fact, one register write is all that is required, but you need to write 0x29 to the misc register (addr 0x03), not 0x09 as they suggest. Damn hell!
Should I open a tech support case and suggest them to correct the datasheet? Would probably save hours of time to others.
Well, the connectors on these boards are completely different, weren't designed with any compatibility in mind. There are signals specific to either of the IC. But sure, thinking about compatibility, should spare me an hour or two of soldering the ribbon on ;D
I had to pause a bit with toying with this, we've had just a home solar power station installed. Lot of interesting stuff was happening and there is even some room for diy improvements to exploit. (Such as intercepting the CAN bus in between the inverter and battery management system or making remote configuration access to the transfer switch - it has only a USB port for local access). ;)
-
I think you should drop support a mail, and at least they could have the pdf on the pin 27 in the download section to the chip.
Sounds interesting with a solar power station, not sure how much a hack can improve the efficiency compared to regular wash of the panels 8)
Let me hear when you are ready for FPGA fun with the video boards, BTW the part-number for you Cyclone chip sound a little bit wrong (I can's find that specific chip in Quartus) try to read what exactly are printed on the chip (not from the Chinese web info)
I did choose the EP4CE6E22C8L instead, just to see how the resources was shown in Quartus
-
I have dropped them a mail suggesting the documentation improvement yesterday evening. A reply came quite fast, that the probably indeed should update the datasheet, since it is already 9 years old. But I have forgot about the document you have found. I will tell them, don't worry ;D
The part no is correct, I have both kits with EP4CE6E22C8N, not C8L, that is a different speed grade or what. I have also 4 spare LQFP chips, all of them are also C8N on the end.
Ah.. I remember now! See the document below Figure 1-3, it is a "C8" grade, and the N suffix is a signature of the lead-free crap.
Yes, ready for the FPGA now, at least to set up an empty project for it. I will try and report back if something goes wonky.
-
I get it, the last letter "N" are non related to the Die but to the pins so in Quartus it will be EP4CE6E22C8. You can try when you have the board hooked up with the JTAG to click autodetect in the programmer and it report what it sees on the JTAG.
-
.. a bit more of our FVE related delay, but I have the project setup and running, successfully compiled the obligatory logic example below.
Programmer does see the FPGA, but only as "EP4CE6", can not resolve any further. Funny it has even asked if I have Cyclone III or some other devices, because someone ... have assigned them the same ID. :palm:
(To prevent possible future confusion, I use Quartus II 13.0.sp1)
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity CycloneIVtest is
port (
A, B : in std_logic;
Y : out std_logic
);
end CycloneIVtest;
architecture behav of CycloneIVtest is
begin
Y <= A and B;
end;
So what should I do next? I could either toy a bit with it to freshen my VHDL-fu a bit (its been years since I have last touched it!) or just go straight into it. But I guess the latter is better, enough blinkelinghts already.
So as a first step, I should hook up the TVP and ADV to the FPGA. Please mind you, I have never done any major HDL designs, in fact never worked with FPGAs, so dumb questions may follow.
I guess it is always good practice to connect a bus clock to a CLK dedicated CLK pin on an FPGA. So the TVP5150 CLK will go to an FPGA CLK input pin.
But what to do with the CLK input pin of the ADV7391? Should I connect it also to the TVP5150 clock, or is there a reason to do it different?
-
So what should I do next?
Good question :)
Sure you can play a bit ad hock to get confident on the Quartus, but you will need to have a plan for what you want the FPGA to do with the signal from the dec/enc and draw a small block schematic in what you blocks need to have in it.
Some ideas
a) Just send all the data inc hte clk into on some pin and out on some other pins between the dec / enc and connect them in the FPGA and see it works without any PLL in the FPGA will be a good start I think
b) Handle the BT656 and you could then add some sync detect to the bus and drive a few pins out and see on the scope that they fit the analog video.
c) Handle the BT656 and generate a local bar to the encoder and switch between loop through and bars
d) Convert the BT656 from Yuv to RGB and back
e) Swap the RBG around / make it BW or inverted
f) Make and overlay of a some simple graphics
g) Write 1 line to RAM M9K and read it out reversed (flip the image)
Regarding to have the clk on a dedicated clk input pin on the FPGA I would not bother taht mutch for that since it's only 27Mhz and should work on all pins, you will have to into which pin bank support the io votage on the dec/enc.
Also I guess you do have a on-board osc. like 50Mhz which are on clk pin that will go to the PLL later on I expect you will use the PLL on eg 27Mhz but it all depend on what the FPGA have to do.
If you recall from 1 of my first post in this thread I quite some years ago did use the Bitec dev. board and I recall there is a BT656 input module... I will try to find it.
-
Here you have the BT656_tx but it's verilog pope do not mind to mix the different modules in different VHDL / Verilog
To use in Quartus:
In your project you already have created the basic of add new file select Design Files and Verilog HDL file
Copy/paste the code into in and save it as BT656_rx.v
Then in the Files select create/update "Create symbol files for current file"
It should hope full work without any error
Back in you top entry (which I expect to be "schematic" double click and select project and add in the the bt656_rx
This should give you a graphic block which you can connect you input and output pins
You sure have to assign the right pins in the pin planner
I do not have the BT656_tx.v but sure it might be out there somewhere or you will have to make your own
// ================================================================================
// (c) 2004 Altera Corporation. All rights reserved.
// Altera products are protected under numerous U.S. and foreign patents, maskwork
// rights, copyrights and other intellectual property laws.
//
// This reference design file, and your use thereof, is subject to and governed
// by the terms and conditions of the applicable Altera Reference Design License
// Agreement (either as signed by you, agreed by you upon download or as a
// "click-through" agreement upon installation andor found at [url=http://www.altera.com]www.altera.com[/url]).
// By using this reference design file, you indicate your acceptance of such terms
// and conditions between you and Altera Corporation. In the event that you do
// not agree with such terms and conditions, you may not use the reference design
// file and please promptly destroy any copies you have made.
//
// This reference design file is being provided on an "as-is" basis and as an
// accommodation and therefore all warranties, representations or guarantees of
// any kind (whether express, implied or statutory) including, without limitation,
// warranties of merchantability, non-infringement, or fitness for a particular
// purpose, are specifically disclaimed. By making this reference design file
// available, Altera expressly does not recommend, suggest or require that this
// reference design file be used in combination with any other product not
// provided by Altera.
// ================================================================================
//---------------------------------------------------------------------------
// BT656 Receiver
//---------------------------------------------------------------------------
`timescale 1ns/1ns
module bt656_rx (
clk,
reset_n,
din,
clk_135_en,
v_blank,
h,
field,
pixel,
line,
y,
cb,
cr
);
input clk; // 27 MHz
input reset_n;
input [7:0] din;
output clk_135_en;
output v_blank;
output h;
output field;
output [9:0] pixel;
output [8:0] line;
output [7:0] y;
output [7:0] cb;
output [7:0] cr;
//---------------------------------------------------------------------------
// Scan input stream to decode timing reference signals
//---------------------------------------------------------------------------
reg [1:0] time_ref;
parameter idle = 2'b00,
ff = 2'b01,
ff00 = 2'b10,
ff0000 = 2'b11;
always @(posedge clk or negedge reset_n)
if (~reset_n)
time_ref <= idle;
else
case (time_ref)
idle:
if (din == 8'hff)
time_ref <= ff;
ff:
if (din == 8'h0)
time_ref <= ff00;
else
time_ref <= idle;
ff00:
if (din == 8'h0)
time_ref <= ff0000;
else
time_ref <= idle;
ff0000:
time_ref <= idle;
endcase
wire timing_ref = (time_ref == ff0000);
reg timing_ref_r;
always @(posedge clk or negedge reset_n)
if (~reset_n)
timing_ref_r <= 1'b0;
else
timing_ref_r <= timing_ref;
//---------------------------------------------------------------------------
// blanking flags
//---------------------------------------------------------------------------
reg field;
reg v;
reg h;
always @(posedge clk or negedge reset_n)
if (~reset_n)
field <= 1'b0;
else if (timing_ref)
field <= din[6];
always @(posedge clk or negedge reset_n)
if (~reset_n)
v <= 1'b0;
else if (timing_ref)
v <= din[5];
wire v_blank = v;
always @(posedge clk or negedge reset_n)
if (~reset_n)
h <= 1'b0;
else if (timing_ref)
h <= din[4];
//---------------------------------------------------------------------------
// Input capture registers
//---------------------------------------------------------------------------
reg [1:0] input_phase;
always @(posedge clk or negedge reset_n)
if (~reset_n)
input_phase <= 2'b0;
else if (h | v)
input_phase <= 2'b0;
else
input_phase <= input_phase + 2'b01;
reg [7:0] y_reg;
always @(posedge clk or negedge reset_n)
if (~reset_n)
y_reg <= 8'b0;
else if (input_phase[0])
y_reg <= din;
reg [7:0] cb_reg;
always @(posedge clk or negedge reset_n)
if (~reset_n)
cb_reg <= 8'b0;
else if (input_phase == 2'b00)
cb_reg <= din;
reg [7:0] cr_reg;
always @(posedge clk or negedge reset_n)
if (~reset_n)
cr_reg <= 8'b0;
else if (input_phase == 2'b10)
cr_reg <= din;
reg [7:0] y;
reg sav;
always @(posedge clk or negedge reset_n)
if (~reset_n)
y <= 8'b0;
else if (input_phase[0] & ~sav & ~timing_ref)
y <= y_reg;
reg [7:0] cb;
always @(posedge clk or negedge reset_n)
if (~reset_n)
cb <= 8'b0;
else if ((input_phase == 2'b11) & ~timing_ref)
cb <= cb_reg;
reg [7:0] cr;
always @(posedge clk or negedge reset_n)
if (~reset_n)
cr <= 8'b0;
else if ((input_phase == 2'b11) & ~timing_ref)
cr <= cr_reg;
always @(posedge clk or negedge reset_n)
if (~reset_n)
sav <= 1'b0;
else if (timing_ref & ((din == 8'h80) | (din == 8'hc7)))
sav <= 1'b1;
else if (input_phase == 2'b10)
sav <= 1'b0;
reg clk_135_en;
always @(posedge clk or negedge reset_n)
if (~reset_n)
clk_135_en <= 1'b0;
else
// Inhibit first and last pulses to prevent clocking out timing codes
clk_135_en <= (~sav & input_phase[0]
& ~(timing_ref & ((din == 8'h9d) | (din == 8'hda))));
reg [8:0] line;
always @(posedge clk or negedge reset_n)
if (~reset_n)
line <= 9'b0;
else if (v)
line <= 9'b0;
else if (timing_ref_r & sav)
line <= line + 9'b1;
reg [9:0] pixel;
always @(posedge clk or negedge reset_n)
if (~reset_n)
pixel <= 10'b0;
else if (h)
pixel <= 10'b0;
else if (clk_135_en)
pixel <= pixel + 10'b1;
endmodule // bt656_rx
-
I know you use the external processor board for I2C but you also need some I2C core if you are not going to have NIOS or external processor involved.
Here is a quite informative video where he writes the I2C core and test it https://www.youtube.com/watch?v=ZJpKK4dIH1k&t=4990s (https://www.youtube.com/watch?v=ZJpKK4dIH1k&t=4990s)
But you can also find ready I2C core many places online
For inspiration: I also suggest the PDF from Intel "Advanced Synthesis Cookbook" for many small nice ideas and trick
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/stx_cookbook.pdf (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/stx_cookbook.pdf)
And you might also like to look around at https://opencores.org/projects (https://opencores.org/projects) and https://www.fpga4fun.com/ (https://www.fpga4fun.com/) and https://www.nandland.com/ (https://www.nandland.com/) just to mention a few
-
I am glad that my plans how to proceed almost exactly match your suggestions. >:D
Sorry that I haven't touched Quartus since my last post, but I thought it'd be good to finish some of the already begun work, rather than opening yet another can of worms right away.
I scored a quad SD-SDI video monitor from ebay for just couple of bucks (shipping was I think more expensive than that thing). It sat like three months dismantled in a pile of other stuff to repair or fix. Few days ago I have finally received the replacement CFL tubes for the displays. The original ones were beyond dead. They couldn't even strike an arc, like if they got air into them. With the new ones and after thorough cleaning, it now works and is in a good shape. Good, not great. Second screen has some issues with sync, fourth one has slightly incorrect color tone. Could be likely tweaked up, but would you want to touch any of the 50 trimpots in there? Certainly not me. >:(
By the way, the screens seem to be some off-the-shelf modules from Sharp with AUOprtronics LCDs (quite surprised they were not Sharp too). The module just receives I think 12V and analog composite video, plus a NTSC/PAL switching signal.
SDI inputs are handled on a custom separate board, made from some pretty oldschool stuff from the CLCxx product line from back then. Crazy power hungry PLCC packaged stuff. Then they've sticked an 8bit D/A after the SDI decoder and pass the composite video both to the LCD module and to a dedicated BNC on the back. (Quite bad they couldn't include another BNC for composite video input too).
So, now I have at least one professionally made SDI sink device (if I don't count the scalers/switcher).
But back to the FPGA stuff. Dinner first, then I prepare a board holder for the thing. I do not like boards flapping in the breeze. Quartus still ready to enter some code.
I2C core? Ugh.. huh. Not enough courage to try that yet. :scared:
-
So I have finally made this obligatory thing working. I can get the BT.656 through the FPGA (working as a simple 1ck delay).
Currently modules all connected using the evil crap arduino wires. Seems signal integrity is not that much of an issue, unfortunately, bad contacts ARE a huge ISSUE and chasing intermittent contacts in stupid wiring always makes me pissed. :box:
I will also now solder down some beefier more stable connections. But am thinking heavily about spinning a custom board for this right now.
Awesome, picture going stably through almost 20 minutes. But I can't touch the thing at all, not even breath around it. :phew:
After that, off the next task: SAV/EAV state machine / decoder.
//yup, I have compiled the project with that typo in the signal - haven't noticed until making the picture ;D//
-
Instead of fixing the wiring, being very impatient, I have tried to decode SAV/EAV. It werkzzz!!!
I have used the code below to decode SAV/EAV. Sure the state machine is not the nicest, I have troubles remembering all the VHDL syntax and does not likely handle all possible issues, nor does it verify the validity using the parity bits. But either way, I am getting nice F, V and H signals out, all of the correctly positioned and as expected. (25Hz F toggle, 50Hz V pulse, 15625Hz H pulse).
Now I should fix the wiring.
-- SAV/EAV state machine
case state is
when State0 =>
if (video_in = x"FF") then
state <= State1;
end if;
when State1 =>
if (video_in = x"00") then
state <= State2;
else
state <= State0;
end if;
when State2 =>
if (video_in = x"00") then
state <= State3;
else
state <= State0;
end if;
when State3 =>
state <= State0;
F <= video_in(6);
V <= video_in(5);
H <= video_in(4);
end case;
-
This is great news :-+
Let us know your progress and if you need any help
-
Great news didn't last long.
I have soldered a more sturdy and reliable wiring. That required reversing the bits on the DAC outputs - I have just mapped the outputs to different pin numbers.
But now, the state machine makes mistakes. I swear it did not do it before! I haven't touched the VHDL code, I have just swapped pins around in the pin planner tool.
WTF is going on there? The video output from the ADV7391 is correct and without those decoding glitches. The whole code is below. No timing constraints were setup (I don't even know how to do so), but I would not expect any problems at 27MHz. I do not have any long combinatorial paths there. Just a dead simple state machine and a few output flops.
Also attaching a capture from my oscilloscope, to see what the problem does. It seems as if it would sometimes miss SAV/EAV, or find one where it shouldn't be. H output in the image below. F flag has random glitches in the output and V output seems okay.
Also my oscilloscope is finaly becoming shot too. Restarts about each minute and freezes randomly. Chinese crap. :horse: :box: :rant: I need to get a new one. Fast. Without one I can't do almost anything. |O
-
I'm done here. The shit just ain't gonna work, now I can't even get video through. Touching random wires has still effect on what it does. How thats even freaking possible is beyond me. All data signal are always paired with a GND wire in the ribbon, alternating signal-ground-signal. The Chinese FPGA board isn't helping much, the layout is beyond horrible (who would have guessed, uh?) and I do not want to waste time with this setup any more. Maybe I could figure all that out in a couple of hours, maybe days. But hell I can find better ways to spend time.
And note, that by using the previous piece of cable just in between the TVP5150 and ADV7391, I get reliable image output. Hence why I suspect the FPGA board. The new cables were made the same, there are no shorts or misplaced wires, I have just checked.
My two small decoder/encoder boards served the purpose - I have already found out all quirks using them, already know the do's and don'ts with these ICs.
Now I need to make a proper board with a proper layout for this, all single board. I will not go yet for the full board I dreamed somewhere on the first or second page of this thread, but at least I will include:
FPGA (this exact EP4CE6E22C8N) + config FLASH (EPCS4N)
TVP5150
ADV7391
some small MCU to handle the I2C (at least for now)
couple of user IO (buttons/switches/LEDs)
probably throw a CLC001/006 in the mix, maybe even CLC014.
Either way, I need to study how to connect the FPGA and all its support circuitry. And also figure out how to interface those PECL chips above with the FPGA.
-
If the video still goes through the FPGA and look good but your stage-machine fails and did work before and the only thing you have done is swapping to different pins I would say that your might have some data lines swapped in both ends ...?
I doubt the 27Mhz timing is the problem.
You could also try the bt656_rx as I posted above
If you want to make a board I get it, but it will slow you down for a few weeks.
Remember the JTAG connector as well
I would also make the I2C ready from the FPGA to the TVP5150 and ADV7391
There are many easy to go codes around to have that to work... just sending the I2C bytes to a given address
Also for debug / testing later on maybe a RS232 (TTL) interface and even 5 pins out for VGA RGBHV (TTL) to have some info coming out.
-
I2C core? Ugh.. huh. Not enough courage to try that yet. :scared:
Based on past experiences, I would suggest "expect pain".
So much pain in fact, that for any new project I always check if there is an SPI alternative available. If yes, *boot* I2C part, *insert* SPI part.
-
If the video still goes through the FPGA and look good but your stage-machine fails and did work before and the only thing you have done is swapping to different pins I would say that your might have some data lines swapped in both ends ...?
I doubt the 27Mhz timing is the problem.
I have only modified the output side pin mapping. The input stayed same. So I expect it should work the same.
Hopefully it won't take me two weeks to finish the board. On the other hand I guess, we will still be locked at home for quite some weeks to come.
So much pain in fact, that for any new project I always check if there is an SPI alternative available. If yes, *boot* I2C part, *insert* SPI part.
Unfortunately both TVP5150 and ADV7391 are I2C only. So *insert* small MCU to do the I2C stuff. :D
-
Unfortunately both TVP5150 and ADV7391 are I2C only. So *insert* small MCU to do the I2C stuff. :D
Yup, that'll do the trick as well. The potential for I2C related "fun puzzles" is so large IMO, that the extra $0.42 for a small mcu is money well spent.
-
You don't tell me, I hate I2C bus and always try to avoid it too. Combined with how shitty implementations the I2C peripherals mostly have in many MCUs, it is even easier at times to bitbang by SW completely. ::)
I have started working on some nice PCB. Originally thought about squeezing it onto 2 layers, but then said NO. Not worth the hassle. 4 layers will save a lot of time in the design process and the result will be better electrically anyway.
Now need to figure out the FPGA, add some MCU and power supply cascade.
Decided to use only CLC001, no SDI receiver. We need to leave something for the larger complex board with SDRAM.
MCU will be also used as a USB-UART bridge to the FPGA too, no worries. Also I'll route the I2C to the FPGA too ;)
-
Yeah don't waste time :-)
What soft do you use for PCB Kicad? Where do you have the boards made?
Add some pin headers so you can hook up some extra wires for unknown test / add-on stuff
-
Like an old fart I still use some old version of Eagle. Because i am used to it and know the limitations well and know how to go around them easily.
I once tried Altium, when I was able to use an official full unlimited license, but I quit with it. Too complicated for the simple stuff I do (or at least I did back then.. it is like... not sure how many years, but it was Altium 15 the latest new shiny version).
Now I would really like to switch to Kicad. Unfortunately, I think it is still a toy, not a CAD. The schematic editor is great, but the PCB editor sucks balls. It misses a lot of really basic stuff, that a usable PCB CAD should have since version 1.
Why have you asked?
I'll try to route out most of the remaining IO, sure. Would be ill-thought not to do so.
//EDIT: Forgot where to make PCBs: I find JLCPCB the best option for me currently.
-
Regarding PCB, I have been thinking for a while to do a 4 layer board with Cyclone V CE A9 (BGA) since I think it's the FPGA where you get most LE for the money and have been playing a bit with the KICAD and think it could work.
I also had JLCPCB in mind since 4 layer can be done for a fair price. I'm not sure but I believe you are in Europe so it was more to know if you had a recommendation here to avoid long shipping and taxes when it comes to EU. But I guess it's hard to beat JLCPCB
-
I am still kind of scared of BGA, I have no longer access to any kind of professional BGA soldering machines. Sure, I have seen small BGAs with large pitch can be easily soldered at home with just hot air and a couple of neat tricks... I have even some projects planned, where there is no way around BGA. For example, I'd like to move to HD- and 3G-SDI later, there are unfortunately not many options to tackle this bitrate without a BGA chip. (couple of EP4CGX22 already waiting here with a couple of GS2971 receivers...) Being able to solder and use these at home would be great.
Almost any kind of Chinese PCB vendor is hard to beat, especially with 4 layer boards. I can get 10 boards from JLCPCB faster and cheaper (including taxes and DHL Express shipping) than a single 2layer pool job from a local vendor. They are very expensive here and have long lead times for 4 layer pooling, DHL will definitely arrive faster with boards from China, then they could manufacture them.
-
A couple of FPGA n00b questions:
1) What may be the expected current consumption of the 2.5V VCCA supply pins of EP4CE6E22? They should be just PLL supply pins. (trying to determine if a 150mA SOT23 LDO would do).
2) How to interface the damn CLC001 (datasheet) (http://www.ti.com/lit/ds/snls066b/snls066b.pdf) cable driver to the FPGA? Seems like I need to "waste" a whole IO bank due to 2.5V VCCIO requirement.
Datasheet mentions CLC001 accepts both LVPECL and LVDS voltage levels. The FPGA can do both LVPECL and LVDS.
Datasheet specifies the input common mode range of CLC001 to be 50mV to 3.25V. Does that mean I can DC couple it to the FPGA? The Cyclone IV handbook (Volume 3 Table 1-20 page 14) (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-iv/cyclone4-handbook.pdf) specifies that LVDS has a Vos = 1.25V. That means choosing LVDS would enable direct DC coupling to the CLC001, with just a single 100ohm termination resistor on the CLC001 side of the line. No other resistors required. Is that correct?
//EDIT: Picture from the handbook below, it seems that's right then...
//EDIT2: Sleep time is calling, enough for today. I don't think this PCB will take weeks :)
-
1) What may be the expected current consumption of the 2.5V VCCA supply pins of EP4CE6E22? They should be just PLL supply pins. (trying to determine if a 150mA SOT23 LDO would do).
I can't find any mA for the VCCA but I would expect that 150mA would be enough, mayby you can messure it on your own board (remember to add 2 PLL's and run them eg @ 100Mhz and 200Mhz)
Here https://www.waveshare.com/wiki/OpenEP4CE6-C_User_Manual (https://www.waveshare.com/wiki/OpenEP4CE6-C_User_Manual) they use the AMS1117-2.5 so if your 150mA are not good enough you can swap the LDO later on
2) How to interface the damn CLC001 (datasheet) (http://www.ti.com/lit/ds/snls066b/snls066b.pdf) cable driver to the FPGA? Seems like I need to "waste" a whole IO bank due to 2.5V VCCIO requirement.
Datasheet mentions CLC001 accepts both LVPECL and LVDS voltage levels. The FPGA can do both LVPECL and LVDS.
Datasheet specifies the input common mode range of CLC001 to be 50mV to 3.25V. Does that mean I can DC couple it to the FPGA? The Cyclone IV handbook (Volume 3 Table 1-20 page 14) (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-iv/cyclone4-handbook.pdf) specifies that LVDS has a Vos = 1.25V. That means choosing LVDS would enable direct DC coupling to the CLC001, with just a single 100ohm termination resistor on the CLC001 side of the line. No other resistors required. Is that correct?
I agree it look like one 100ohm resistor can do the rick and you can leave the I/O Bank as you have it
The CLC001 needs 3V3 Vdd :) you might like to have 1 Bank running 3V3 for unknown purpose
You can test it on you board just send the 27Hhz to LVDS pins and hook up the CLC001 and look at the scope
-
Thank you for confirming my thoughts.
I meant that only the bank with LVDS used needs to be supplied with 2V5 and I have selected bank 6 to do so. One with the least amount of pins and also right side of the die, where the true LVDS drivers are. All other banks will have 3V3 VCCIO.
Yesterday I did nothing with the board, some work troubles and related stuff. But I'd like to continue today.
I have found another interesting issue to think about:
How to connect the clock line of ADV7391?
With the TVP5150, I can route it simply to any of the CLK pins nearby. But I can't connect it together to the ADV7391. Imagine the following: I'd like to use the FPGA to generate video signal, such as a test pattern generator. The ADV7391 can do much higher resolutions than SD, so I would need a completely different (and independent) clock from the FPGA. Where should I route the ADV7391 CLK pin then?
Likely any of the generic IOs, huh? But in case I would like to run in sync with the clock from TVP5150, how do I route the clock through the FPGA? The CLK signal delay within the FPGA may then cause incorrect timing on the output side. Not sure how to solve this one. Could you please give advice? ???
//EDIT: I have also doubly solved my oscilloscope issue: I have ordered a new one: Rigol DS1104Z. Its also Chinese one, but hey, shall be way better than the Hantek DSO5202B I got here for the last so many years. At least the Rigol should have a proper intensity grading display and 4 channels.
I also got at home an old Agilent 3062A, that desperately needed some encoder change-out I have already done yesterday evening. A pretty boring oscilloscope nonetheless with absolutely horrible LCD screen, but at least I have a working backup for some basic poking.
-
How to connect the clock line of ADV7391?
With the TVP5150, I can route it simply to any of the CLK pins nearby. But I can't connect it together to the ADV7391. Imagine the following: I'd like to use the FPGA to generate video signal, such as a test pattern generator. The ADV7391 can do much higher resolutions than SD, so I would need a completely different (and independent) clock from the FPGA. Where should I route the ADV7391 CLK pin then?
Likely any of the generic IOs, huh? But in case I would like to run in sync with the clock from TVP5150, how do I route the clock through the FPGA? The CLK signal delay within the FPGA may then cause incorrect timing on the output side. Not sure how to solve this one. Could you please give advice? ???
I think:
The ADV7391 clk needs to come for the FPGA and not directly from the TVP5150 so you can program it via PLL or switch to internal global clocklines
Since we still talk about relative low freq I think you can use whatever outpin to drive clk on the ADV7391 to have the data "aligned" with the clk just send them trough registers clocked with the same clk and if should be in phase on the output eg if you do a test signal
On the ADV7391 eval board ADV739x_EvalBrd_RevB.pdf http://media.digikey.com/PDF/Data%20Sheets/Analog%20Devices%20PDFs/ADV739x_EvalBrd_RevB.pdf (http://media.digikey.com/PDF/Data%20Sheets/Analog%20Devices%20PDFs/ADV739x_EvalBrd_RevB.pdf)
you can see the have 27Mhz (SD) and 74,25Mhz (HD) to pin 55 and 56 (global clk lines) on spartan 3 and the they have clkout on pin 74 output on pin which goes to clk pin on ADV7391
And data clk into pin 53 and 125 via jumper as if it came from the TVP5150 to global clk lines
If they are routed to PLL or not I don't know since the HDL source for that board seems to be only available if you buy it (or I just can find it)
page 146 https://www.xilinx.com/support/documentation/data_sheets/ds099.pdf (https://www.xilinx.com/support/documentation/data_sheets/ds099.pdf)
55 IO_L32P_4/GCLK0
56 O_L32N_4/GCLK1
74 IO_L01N_3/VRP_3
I have ordered a new one: Rigol DS1104Z
I love when new equipment are ordred :) sure you will happy for 4 channels :-+
-
Or I can put a jumper in there, to select clock in between a random IO pin and to connect together with TVP5150 clock. That could I think be possible too.
I have ordered a new one: Rigol DS1104Z
I love when new equipment are ordred :) sure you will happy for 4 channels :-+
If I just could find out about Siglent SDS1204CFL, I would have probably bought that one. I like the dedicated knobs.
What I have found interesting, is that my freshly repaired Agilent DS3062A scope is in fact made by Siglent, not Agilent. ;D
-
Or I can put a jumper in there, to select clock in between a random IO pin and to connect together with TVP5150 clock. That could I think be possible too.
I have ordered a new one: Rigol DS1104Z
I love when new equipment are ordred :) sure you will happy for 4 channels :-+
If I just could find out about Siglent SDS1204CFL, I would have probably bought that one. I like the dedicated knobs.
What I have found interesting, is that my freshly repaired Agilent DS3062A scope is in fact made by Siglent, not Agilent. ;D
Yes to Jumper, but maybe as solder connection to avoid RF issues in the connections over time
I have a 4ch Agillient DSOX2014A now Keysight and way back HP, great scope with a lot of options 8)
-
Agree, will use a solder jumper there.
That kind of oscilloscope is way out of my budget, unfortunately. If I would have that much to spend, I'd be likely looking for a new spectrum analyzer, to replace the aging one I have.
A little bit of an update: Board space is filling up nicely :) Been doing research around how to connect the configuration pins, FLASH and JTAG connector. I would like to also add some kind of a user button/switch. Already having 4 user LEDS, but being able to add something like a 4-way DIL switch, would be handy.
Also there is a 36pin header ready for future expansion and stuff. The MCU is supposed to make a USB to UART/SPI/I2C bridge. All these three buses will be connected to the FPGA of course.
I will publish the schematic and layout for review later, currently still working on both on the fly.
-
Little update with the board, see below. TVP5150 fully connected, IO expansion header also connected.
Today, unfortunately, I will again have to do some work related stuff, so will not probably do much progress either. At least I will figure out what to slap in the free space on the right. I don't like wasted space on PCBs :)
The 34 pin (there was a mistake, 36pin is NOT a standard IDC size, I had to shave 2 off*) header provides 20 IOs directly to the FPGA - should be plenty for some future toying. Provides also a lot of grounds, 3V3 supply voltage, the system I2C bus and a global /RESET signal for all peripherals.
-
When I bought that scope like 7 years ago there was a huge offer / campaign at that time like almost half price, I newer regret it I bought it, special when there is a very good thread her in the forum with a good tricks 8)
Nice progress with your board :-+
YES have some dip SW and a few push buttons so you can easy trigger or select some part in the FPGA, very handy when debugging in real time. You have the IDC pins but say if you still have some spare I/O, you could use them as test connections (small rings) next to the edge to attach scope probes and also make an easy and steady connection for scope ground.
-
I plan to put testpoints all over the board, ideally on all signals. Not sure how many spare IOs the FPGA will have, but I guess some will be left on the top side of PCB, estimating one whole bank free (~15 IOs?)
Of course it would make sense to break out as much pins as possible. Will put some thought into it. .. .after I deal with the work related stuff now. :rant:
-
If you can run that 1 IO bank at 1.8v, add this 1 chip which will use 12 IOs, even if you never populate it.
https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/S70KS1281DPBHV020/2015-S70KS1281DPBHV020-ND/9955180 (https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/S70KS1281DPBHV020/2015-S70KS1281DPBHV020-ND/9955180)
-
Very interesting interface that memory has. Never seen one like this. I hate BGA packages (not enough experience with them yet), but a 5x5 ball 1mm pitch looks as a nice beginner BGA chip, doesn't it? Almost looks like a challenge to try. However it is quite on the expensive side, for just a DRAM.
The other board I plan to make will have a "classic" SDRAM with a 16bit wide IO. Probably easier to start with, rather than the beast above with DDR and all sorts of hurdles? I smell way more complex interface than that of a classic cheap SDRAM.
Now I need just a board to start with simple video and even simpler VHDL stuff. Anyway thanks for an interesting tip.
-
Very interesting interface that memory has. Never seen one like this. I hate BGA packages (not enough experience with them yet), but a 5x5 ball 1mm pitch looks as a nice beginner BGA chip, doesn't it? Almost looks like a challenge to try. However it is quite on the expensive side, for just a DRAM.
The other board I plan to make will have a "classic" SDRAM with a 16bit wide IO. Probably easier to start with, rather than the beast above with DDR and all sorts of hurdles? I smell way more complex interface than that of a classic cheap SDRAM.
Now I need just a board to start with simple video and even simpler VHDL stuff. Anyway thanks for an interesting tip.
It has a built in DRAM controller (this is why it is expensive). All you need to do if feed an address and either write data, or wait for the read data ready flag and receive data. It handles the refresh and sequence timing internally. Logic wise, a simple state machine with a home made FPGA FIFO line buffer, and you will have enough speed for NTSC 4 field processing like XYZ 3D comb filtering dot crawl removal and noise removal, and/or 480i to 480p de-interlacing processing if your encoder/DAC supports 27MHz 1:1 through mode. (Some NTSC encoders do support 480p as well)
Your FPGA already has enough in it to do 3 line XY filtering like median noise filter, sharpen & blur, the ram brings this into 3D-Z processing.
A single 5x5 1mm BGA can be placed with just some solder on the pads, a blob of flux and hot air.
https://youtu.be/2eXMFIkdA0o
The ram chip may be cheaper from somewhere else other than Digikey.
-
Well, I can try fit it there, but that's another likely whole day of fiddling to get the BGA on the board. I'd rather leave fiddling with external RAM for next attempt. Now I'd be glad if this board would work as it should as it is.
You know that I am no VHDL/FPGA expert, don't you? My freaking blinkenlights project with UART transmitter doesn't qualify me for 3D-Z processing, at least not yet. I'd be plenty happy if I could insert some dumb text into the video. :-//
And regarding Louis:
"How hot is your air gun?"
"I dunno. Whatever it needs to be to melt shit. If it's not hot enough to melt shit, turn it up!"
I need some BGA practice first. :scared:
-
If you can run that 1 IO bank at 1.8v, add this 1 chip which will use 12 IOs, even if you never populate it.
https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/S70KS1281DPBHV020/2015-S70KS1281DPBHV020-ND/9955180 (https://www.digikey.com/product-detail/en/cypress-semiconductor-corp/S70KS1281DPBHV020/2015-S70KS1281DPBHV020-ND/9955180)
Interesting device, never pay any attention to those but it removes all the refresh issues :)
How fast is it?
If you have like 2 SD (or more) video inputs you could sure use it as framebuffer to make sync / zoom, freeze etc, but I suspect there would be limitation if eg you should use it for a 90 deg rotation of a video frame (this would normal require SRAM to not be limited to read / write a whole row in DRAM)?
-
A question regarding the JTAG download cable connection: Do the JTAG pins of Cyclone IV support 3V3 levels, or do they not? I am finding confusing and even contradicting information in the device handbook. :box:
Shall I power the JTAG interface from 3V3, or 2V5?
The Cyclone IV device handbook (page 211) (https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-iv/cyclone4-handbook.pdf) tells me to power the JTAG interface from the VCCA (Analog! 2V5) supply. WTF! Is that a misprint or what?
And I have checked on the small FPGA kit I got and the JTAG cable is powered from 3V3.
Then I have checked the larger FPGA kit I have and the JTAG there is also powered 3V3.
Also I am not finding any information, that would prohibit me from applying 3V3 to the JTAG interface. Table 1-1 the Absolute Max Ratings just generically states a maximum input voltage is 4.2V. Hence I think that applies even to JTAG pins.
Yes I have also noticed there are no clamping diodes on the JTAG pins, I have added a diode array on the PCB to solve that.
For device using VCCIO of 2.5, 3.0, and 3.3 V, refer to Figure 8–23. All I/O inputs must maintain a maximum AC voltage of 4.1 V because JTAG pins do not have the internal PCI clamping diodes to prevent voltage overshoot when using VCCIO of 2.5, 3.0, and 3.3 V. You must power up the VCC of the download cable with a 2.5-V supply from VCCA.
But WHYYYYYYYYYYYYY |O
-
Pcb is finaly done! Took a day more than I thought. But still, quite fast if I would sum all hours up. The layout is not the best, but 've at least tried. ^-^ (Still likely better than that cheap Chinese kit and wire nest).
Please find below some fancy 3D views and a schematic of the FPGA connections - if anyone would like to have a peek and confirm no obvious rookie mistakes have been made there.
My comments to the schematic:
VCCINT = 1.2V, VCCIO = 3V3 except one bank with LVDS (VCCIO = 2V5), VCCA = 2V5
MSEL(2:0) pins configured according to device handbook page 173, table 8-5 as "010" (POR Delay standard, 3V3 config). Log 1 is at VCCA (2V5).
JTAG cable powered from 3V3 VCCIO - I have copied what works for others. Pinout should match USB Blaster. ESD protection and clamp diode array added to JTAG interface.
Please check the configuration FLASH is connected to the correct pins. I use the original recommended EPCS4 device (but sure I know it is a bog standard 25 series FLASH).
nCONFIG pin can be triggered by the onboard MCU via USB command (at least that is the plan - if wondering where the pin goes)
54MHz XO clock provided to the CLK1 net, 27MHz clock from TVP5150 provided to CLK7 net
-
Approximate ram speed:
100 megabytes per second with a burst length set to 16. (Using 27Mhz X 6 in PLL X2 for DDR = 324 MTPS)
Add 50% for a burst length of 32. Speed improves further as you increase burst up to 128.
For a 90 degree rotate (really advanced, even more so than 3D XYZ image filtering/processing), you do realize that NTSC&PAL are interlaced, without deinterlacing, you will have crap results, but if 240p is acceptable (old super-nintendo type resolution), then you are ok. You also want 4 fields of memory for de-interlacing. That's a good 16 megabytes for 422 16bit color PAL. 1 entire ram chip.
Also, with the memory bursts being sequential, and if you want to use a burst of 16, you will need 3 blocks of 16 line buffers inside the FPGA where you store a triple incoming video buffer where you rotate chunks of display in blocks of 16x16 pixels over an entire 16 lines of video.
This means that you would want (say for efficiency in allocation within CycloneIV M9K ram blocks):
720 pixels x 20 bit color x 16 lines x 4 buffers =
1024 x 18bits x 16lines x 4buffers = 1179648 bits of FPGA ram = 128 M9k CycloneIV ram blocks.
The smallest Cyclone IV has only 270kbits, or, 30 M9k blocks.
If you do some trickery to get the line buffers down to 16lines by 1 buffer, you still need 32 M9K blocks.
I would recommend using the EP4CE10 as it has almost double the M9K blocks of ram at 414kbit, or, 46 M9K blocks.
(No matter how you allocate ram in Quartus, it will always round up to 1 M9K block at a time, or if you go above 9 bits to 10 bits, this also may double your allocated memory as is will be considered an 18bit wide ram with the final 8 bits ignored. The compiler may attempt some optimizations depending on memory depth and how it may divide into a single M9K block.)
(Except for 2 or 3 pins different, the 144pin QFP EP4CE6 and EP4CE10 a almost pin for pin compatible. Make sure your PCB is already wired to accept either both FPGAs. The larger 144pin EP4CE15 and largest EP4CE22 have a few IO swapped to VCCint and GNDint. If you don't need those particular IOs, you should move them to the larger EP4CE15/22 and in Quartus, even if you placed the smaller FPGA, just set those IOs to unused inputs. This way you can use any FPGA size if you ever need to.)
Don't forget to add a dummy TTL RS232 IO port for good measure.
That big hole under you FPGA, I assume you will be filling it with solder as the heat sink?
Also, here is another third party schematic as reference for the JTAG and AS (Active Serial port), and serial prom wiring for reference:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/?action=dlattach;attach=871688 (https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/?action=dlattach;attach=871688)
I don't see any protection diodes on the JTAG and it is being powered from the 2.5v regulator with 2.5v on the pullups. The AS active serial port is using the 3.3v.
This board has been used extensively here:
https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2783910/#msg2783910 (https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2783910/#msg2783910)
We know it works.
-
I thought E4CE6 and EP4CE10 in E144 package are 100% compatible. So what pins are not? I did not see a difference in between them. Better ask and solve that now than later. ???
The board I've made has a small MCU on it, that can act as a USB <> UART/SPI/I2C bridge. (Only later I have realized I could use it as an FPGA programmer, using the PS configuration mode (Passive Serial) - so just maybe on the next board).
Yes that hole below is to solder the exposed pad. I could try solder it using just paste and hot air, but I doubt I could center it on the pads while hot-airing it down or risk damaging an IC or two. I know this hack is ugly, but should lead to a working result.
-
Approximate ram speed:
Thank you for pointing out the RAM requirement for the video handling, very informative :-+
My question were a bit more on the PSRAM device itself what is the worst case speed in the device if reading / writing just 1 byte in random location (that was why I mention rotation since you have to swat the row / column)
Normal DRAM perform badly in "just" 1 byte since you have to read/write the whole and SRAM excellent so I guess the PSRAM will be slow as well, is that correct?
A few interesting links to video rotate I had in bookmark
http://www8.cs.umu.se/education/examina/Rapporter/robertn.pdf (http://www8.cs.umu.se/education/examina/Rapporter/robertn.pdf)
https://web.wpi.edu/Pubs/E-project/Available/E-project-012317-181821/unrestricted/slammqp_final.pdf (https://web.wpi.edu/Pubs/E-project/Available/E-project-012317-181821/unrestricted/slammqp_final.pdf)
https://weekly-geekly.github.io/articles/325236/index.html (https://weekly-geekly.github.io/articles/325236/index.html)
-
Thanks for sharing the papers, I am currently reading the first one and I find it pretty interesting!
//I almost am accepting as a challenge now to try implementing it. Great stuff!
//I've also found an interesting and very cheap video encoder by reading the paper: Philips SAA7120. Great!
//This looks it uses the same algorithm (I mean the rotozoomer), although I can't really orient myself well in the VHDL code from that project:
http://www.elektronika.kvalitne.cz/PLA/TFT_tests/TFT_tests_eng.html (http://www.elektronika.kvalitne.cz/PLA/TFT_tests/TFT_tests_eng.html)
-
//This looks it uses the same algorithm (I mean the rotozoomer), although I can't really orient myself well in the VHDL code from that project:
http://www.elektronika.kvalitne.cz/PLA/TFT_tests/TFT_tests_eng.html (http://www.elektronika.kvalitne.cz/PLA/TFT_tests/TFT_tests_eng.html)
More rotozoom https://www.fpga4fun.com/GraphicLCDpanel3.html (https://www.fpga4fun.com/GraphicLCDpanel3.html)
-
Although it is a verilog, I can see it there.
Meanwhile the PCB is being manufactured, I could probably play with one of the FPGA kits I have, to at least get some practice in VHDL. So let's begin with some blinkenlights again ;D
-
It is surprising how much can one forget, if not using a skill. I haven't touched VHDL for like what... maybe 4-5 years?
A simple blinkenlight LED display counter took me almost 2 hours to figure out. (The syntax and strict type policies are just an awful stuff!)
[attachimg=1]
And sure even those 4-5 years back I wasn't any kind of expert. Hopefully I will now have more time and more useful ideas what to do with an FPGA, that will keep me learning further.
Now I have a week (or maybe two) to play with blinkenlights to gain some of the knowledge back, before the PCBs arrive. :)
-
After taking a bit of break from video and toying with VHDL at other projects, look what we finally got here!
A PCB to presumably solve the damn wiring issues! Very interested to see if it'll work ???
Also made some other accessories to toy with, such as an I2S ADC and DAC and a TOSLINK interface, so I can try also S/PDIF or tackle ADAT or what not.
//EDIT: Just spotted a first mistake on the FPGA board. Fuuuuuuck!
-
After taking a bit of break from video and toying with VHDL at other projects, look what we finally got here!
A PCB to presumably solve the damn wiring issues! Very interested to see if it'll work ???
Also made some other accessories to toy with, such as an I2S ADC and DAC and a TOSLINK interface, so I can try also S/PDIF or tackle ADAT or what not.
//EDIT: Just spotted a first mistake on the FPGA board. Fuuuuuuck!
Looks good and pretty quick delivery :)
Hope the error you have spotted can be fixed and the board still can be used
-
Nothing major, just a polygon got poured improperly and is not making contact. God knows how that happened, as I always run the DRC before generating manufacturing data. >:(
-
Good news everyone!
I have soldered the FPGA and necessary circuitry around it. Successfully connected via JTAG, identified, configured and programmed the conf FLASH. Awwwsome, I am one satisfied person now. ^-^
Now let's solder the rest of it.
-
Great 👍
-
Now waiting for the rest of components to arrive, I could only do that much. I have decided to give LCSC.com a try, however, I have found quite a few issues with that. I have done so due to thinking (and reading everywhere) about how one could combine shipping of JLC PCBs with LCSC. But that is no longer the case.
The pricing of the regular components isn't that much better compared to local distributors, if you are not looking for the cheapest of the cheapest. Well, I wouldn't mind that - as that may be the obvious. But later on, you will find about what bullshit shipping prices are set at. The shipping price seems to be constantly inflating with the sum of the components, making the total price almost twice in size. By adding the VAT and customs fees to it, you end up with even bigger sum.
That way, it is no longer that much favorable to order from LCSC, I can order locally for almost the same price - with one exception - I get the parts FAST.
Although, I have the boards already at home delivered (I'd say within a pretty normal timespan for JLCPCB), seems the package of components haven't even left Shenzhen yet, according to the tracking information provided. :box:
And I was tricked into selecting the most expensive shipping option, to have it "fast". I am very disappointed now. The shipping of components was more expensive by itself, than the whole order of PCBs.
Unfortunately, few key components, such as the MCU is in that order. |O
-
So bad when you have expected 1 shipping (1 cost) special if in the EU due to taxes, on the other hand sometimes it's cheaper to buy stuff eg from ebay in 2 individual orders (if free shipping) to be "below" the tax trigger amount.
At lest you have the FPGA running and can do some testing even if you do not have the MCU mounted, you mentioned you had the I2C connected to the enc/dec and FPGA you could try a I2C interface and see if you can have it up running to see the reg correctly
-
The I2C is available even on the IO expansion pinheader, so I can "hack it" from outside easily. Currently, I am busy with some work related stuff, more soldering in the evening.
EU tax is fine, I have the understanding that VAT has to be payed (no customs % on electronics import yet, luckily). I do even understand they want the VAT payed on every piece of package from 2021 forward. But as always, the style how laws are made in the EU, is downright wrong. How is that even possible, that it is legal that a shipping company can parasite on the VAT you pay with their own fees? How's it is even possible or legal, that for a 22€ package I pay 4.6€ VAT to the state plus another 20€ fee or even more per package to a shipping company that delivered the package? As an end cutomer, I don't give a rat's ass where the money from the fee goes, what matters, is that I have payed 100+% of the total price import fee for that pacakge. So I have overpayed the package more than twice! Fucking stupid.
And sure, there is no way to avoid these "additional fees", as they seem to be just legal. Every company, including the state post company parasites on this, legally.
But enough rant, this would give for a whole and inappropriate topic here.
-
LCSC components arrived late Friday (yesterday)... phew... Almost thought I will get it Monday.
Finally all soldered, except the missing CLC001 cable driver, I could not get. So it indeed took 2 weeks from designing the PCB up to having one soldered. Whatever... Better than wrestling intermittent arduino wires and piss-poor signal integrity.
Board seems working well so far. FPGA tested - can be programmed, including the config FLASH, now blinking the onboard LEDs.
The USB microcontroller works fine too, although I couldn't get the same one with larger flash, so it may need an upgrade. <6kB FLASH and <3kB RAM free, after the USB-CDC stack implementation. USB works too.
Now I need to massage the I2C a bit and try to communicate with the TVP5150 and ADV7391. Then try to shovel the video data through the FPGA and pull the video through the board.
-
Looks very nice, good job :-+
And done very fast, hope it works first time :)
-
I fucking hate the I2C bus! :box:
Seems I can't get an acknowledge from the ADV7391 when trying to read from it.
But if I control this new board from an external kit with different MCU (the one I have used in the previous attempt where the small modules were interconnected by wires - using the same original software) it just works and the ADV7391 responds to read.
What the hell is going on there? Why don't I get an ACK on the read address 0x55?
It clearly responds on 0x54 for write and even works (I can even set the ADV7391 to produce PAL color bars). But I can't read from the ADV7391 with the onboard MCU. Strange... Very strange...
//Scope image below shows an attempt to read the value in reg 0x82.
-
Sure, just have confirmed again, if I hack on the bus external kit with MCU (however, quite different one), I can read from the ADV7391 no problemo.
But I don't seem to find anything wrong with the waveforms captured above, do you?
-
Just to be sure, the I2C does need to have do you have pullup resistors 2x4k7 at the SCL and the SDA bus, what do you have ?
-
2x 1K5 (this is 3V3 logic and I want some speed too :) )
I have solved the issue - by shuffling a bit with the vendor I2C libraries on the MCU. Not sure what has changed, the waveforms look exactly same to the human eye. Just used a bit different functions to exercise the I2C.
So I suspect it was a timing issue. But hard to tell what timing, the I2C is running 30kHz. That'/s hardly SPEED. The I2C peripheral works fine, even clock stretching works (I have accidentally discovered that the TVP5150 uses clock stretching!)
What's interesting is that I could read the TVP5150 through the I2C no problems even before toying with the I2C libraries.
Then, after seeing this:
https://ez.analog.com/video/f/q-a/114768/adv7391-adv7393-i2c-problem
I am not sure what to think about it. It is always an IC from ADI, when the MCU communication port is crippled or badly executed. Already seen quite a few ICs from ADI with strangely behaved interfaces. But I am not here to judge the I2C interface. Lets go on with the FPGA!
So it seems the whole board should be now working. Tomorrow I will cobble some simple VHDL code to test if I can get video realiably through.
-
So it seems the whole board should be now working. Tomorrow I will cobble some simple VHDL code to test if I can get video realiably through.
Long time :o I like the SDI on FPGA project and normally you are very fast, any success yet?
-
I am sorry, a lot of other stuff kept me busy and we are slowly starting to work again as restrictions are lifted in our country, so I'll have less and less free time from now on. :-\
At least now I got two or three days off, so I can probably move forward with this project. I'll report back later, I hope I can toy with it today afternoon or in the evening.
//EDIT: Did not have any spare time today either, but I swear tomorrow I will . :-/
-
We are just beginning to tackle an I2C interface right here:
https://www.eevblog.com/forum/fpga/adc-in-altera-cyclone-fpga/msg3073112/#msg3073112 (https://www.eevblog.com/forum/fpga/adc-in-altera-cyclone-fpga/msg3073112/#msg3073112)
But we are doing it in Verilog. Depending on the OP's speed, it should be at it's second level with even eeprom read & write support within 10 days.
-
Thanks for posting, unfortunately I am still too busy to do anything past writing a few posts here and there.
Currently left all I2C weightlifting to the onboard MCU, but sure I would like to learn more. :-/O