Video IP Scaler control

[Altera_Forum]

Hello, 

 I'm having trouble using the Scaler in the Video IP suite. I have instantiated the scaler using the megawizard and my control logic is custom.   I have instantiated a fixed scaler in my system and it works just fine (no input or output sizes needed on the ST or MM interfaces). When trying to set the input and output image sizes the scaler accepts the first few pixels and then deasserts din_ready never to assert it again.   I am configuring the scaler in the following way.  Reset Scaler.  Avalon MM interface : Set go bit to zero. Wait for status bit to be zero. Set the go bit to one.  Avalon ST interface : Send control packet (startofpacket & Data = 0xF) Send Width and Height nibbles. Send control packet (endofpacket & Data = 0x0(progressive)) Send control packet(startofpacket & Data = 0x0(Video data)) start sendig data.  the scaler takes 3 pixels and then deasserts din_ready and the video flow stops.   How do the width and height nibbles fit into a parallell data stream of 8 bits per pixel and 3 color planes in parallel. the documentation is a little unclear and I have tried some different nibble groupings.  Any help or pointers would be greatly appreciated !  Thanks :D

[Altera_Forum]

are you sending it big endian? ie msb first?

[Altera_Forum]

The data is aligned as follows in the three color planes 8 bit RGB, 24 bit data bus into the Scaler following the ready latency of 1. 

  sp d0 d1 d2 ep 19:16 x W1 H2 x x 11:8 x W2 H3 H0 x 3:0 F W3 W0 H1 0x0  sp start of packet ep end of packet  Width nibbles W(3-0) Height nibbles H(3-0) interlace at end of packet 0x0  this is where I was not able to find a lot of documentation   thanks for the reply

[Altera_Forum]

should be this for 8 bit data in 

 sp w3 w2 w1 w0 h3 h2 h1 h0 interlaced eop  so for 24 bit  byte 2 | w1 | h2 | interlaced byte 1 | w2 | h3 | h0  byte 0 | w3 | w0 | h1  | sop | | eop  where the w and h values are all nibbles  spacing sucks. | is a delimiter

[Altera_Forum]

dwesterg beat me to it. I'll make one modification: 

 Here is what the control packet looks like. I'm assuming 8-bits per color plane with 3 color planes in parallel. The pertinent bit of the 24-bit dout_data would be as follows for the individual cycles:  cycle 1 2 3 4 bits 3:0 0xf w w h bits 11:8 0 w h h bits 19:16 0 w h ilace sop eop   Jake

[Altera_Forum]

Thanks guys,  

 I had it mostly correct except for end of packet. Rebuilt and ran but same problem din_ready from the scaler gets deasserted after 3 pixels :rolleyes: on the avalon MM side i'm just writing in the output width and height as 32 bit unsigned numbers and setting the "go" bit. Could there be an issue there ?

[Altera_Forum]

Did you look at the dout signals. Is something hung up downstream? 

 Jake

[Altera_Forum]

Yes dout_ready is asserted the whole time.....

[Altera_Forum]

Are you doing this on a custom board or a development kit? 

 Jake

[Altera_Forum]

This is a custom video processing pipeline that I am adding a scaler to. The scaler was generated with the megawizard and instantiated in my system.  

 When I change to a fixed scaler (No Avalon MM interface) the scaler works fine. There is not an issue with data flow, I have to be setting up the run time parameters incorrectly....   thanks

[Altera_Forum]

Well, it could be your setting the parameters incorrectly. It could also be that your VIP control packets are incorrect. The scaler ignores control packets when it is set to a fixed size so it likely wouldn't have seen any issues. 

 One last thing ... are you properly giving "0" when you give the startofpacket for the actual video packet?  Jake

[Altera_Forum]

Thanks again Jake, 

 Here are some waveforms (attached pdf) of the Avalon ST and MM interfaces as they are being programmed in my system. Should be easier to see this way :D

[Altera_Forum]

What I think would be more telling is a signaltap shot of the av-st interfaces both into and out of the chip for the duration of the control packet, and the beginning of the video packet. 

 Jake

[Altera_Forum]

Jake, 

 Here is the snap of the AV-ST interface where we see the control packet going in and out of the scaler. The scaler drops din_ready after a couple of din_valid's and does not reassert ready.  thanks again for your help.......   ks

[Altera_Forum]

Okay there is your problem. With avalon streaming interfaces, there is the notion of "ready latency". The VIP components use a ready latency of "1" on the AV-ST interfaces. Your screenshot shows your are using a ready latency of 0. 

 Please reference section 6.3 of: http://www.altera.com/literature/manual/mnl_avalon_spec.pdf  and page 4-11 of the VIP user guide: http://www.altera.com/literature/ug/ug_vip.pdf?gsa_pos=1&wt.oss_r=1&wt.oss=ug_vip  Jake

[Altera_Forum]

I think I am following the ready latency of 1 as specified. In each case I am supplying din_valid one clock cycle after din_ready, that is the way the logic is setup anyhow.  

 What specifically am I doing wrong ? Hopefully it is wrong I would like to get this working.....  thanks again for the replies.  ks

[Altera_Forum]

My apologies. I got confused looking at the waveform and mistaked din_valid for din_ready. You are correct, you are adhering to the ready latency of 1. 

 Have you tried reading the status register of the scaler to see what it claims?  Jake

[Altera_Forum]

Good Idea I'll give that a try. I read somewhere that the output width and height (Regs 2,3) of the scaler are write only do you know if you can read them ? 

  thanks again....  ks

[Altera_Forum]

I would treat them as write only. If I remember correctly from discussions with the video IP designers that it actually depended on which device family you were using. And if memory serves it seems if you try to read them all you get back is 0xffffffff. But it will be interesting to see if the status register claims that it is outputting video data. 

 Jake

[Altera_Forum]

Status register is indicating that it is not busy, Status[0]=0 :rolleyes: although I am giving it the startofpacket with 0x0 (video) type. 

  thanks,  ks

[Altera_Forum]

Have you also read the go bit back from the control register to verify it got set?