On 10/2/06, Nicholas <[EMAIL PROTECTED]> wrote:
> Could someone help me with the spec on the TV chip?  In other words,
> could I get someone to read it for me and then answer specific
> questions?

I can look through it, and try to help, but I don't really have any
experience with anything beyond simple NTSC in the video category.

> Actually, at the moment, the main question is what is the pixel
> interface like?  It appears to be DDR, very much like a single-link
> DVI transmitter.

Do you have a link to the datasheet? I couldn't find it anywhere on the
wiki.

The chip is the Conexant CX25874.  They told us that we'd be able to
get specs on it that we can share, so if you can't find the datasheet
online, we'll get it to you.

I made a really bad test interface for the DVI output module.
This was really quickly hacked together. It is supposed to be a signal
generator for the video, but I am sure it fails miserably since I
haven't done Verilog in a while and don't really understand DVI video
sync. I had two big questions about what I was writing:
1) how do you define constants? I like having nice descriptive names,
and constants allow me to easily change the value. I googled it and
found "specparam", but it wasn't working.

`define const_name value

or

parameter const_name = value;

Parameters do double-duty as both a way to define a constant and a way
to define configurable parameters for module instantiation (like the
way we instantiate fifos of whatever width we need at a give place).

2) What is the difference between "<=" and "="? I thought that "=" was
non-blocking, but after rereading your tutorial, I came across:

Think of "blocking" as "the simulation of the particular piece of
behavioral code 'blocks' until it finishes and is assigned to the
variable."
"Non-blocking" is "the simulation runs past the assignment and doesn't
store the value in the variable until an infinitesimal time delta
later."

        If you were to use blocking assignments, this is what you'd get:

        always @(posedge clock) begin
        x = in + 1;
        y = x + 1;
        z = y + 1;
        end

        time: values
        0: in=3, x='hx, y='hx, z='hx
        1: in=3, x=4, y=5, z=6

I don't understand how this is blocking, since all the computation
occurs in a single time period?

That's what blocking assignments do.  Blocking assignments have
semantics like what you're used to from software programming.

What I want for this code is that assignments like so:
                hstate <= 0;
                horiz <=0;
                vert <=0;
                vstate <=0;
are non-blocking, so that they execute in parallel, correct?

Yes.  Basically.  In hardware that's exactly what happens.  In
simulation, values are stored in hidden temporaries and then stored in
the proper variables later.

In hardware a groups of blocking assignments get registered all in
parallel, independent of one another, even if some earlier lhs is
found in the rhs of a later assignment.

With blocking assignments, the order matters, and so dependencies will
cascade.  A lhs that appears in a later rhs will result in a longer
chain of combinatorial logic.

Also, is there a good resource that explains the DVI interface? I wasn't
really sure what I should send in terms of syncs, porches, etc...

Well... I'm not sure the specifics of DVI affect us TOO much here.
I'm sure we could google for a datasheet for a common DVI transmitter
(like the Silicon Image I164 ir I178).

In short, there are 12 data lines that take data on both edges of the
clock.  IIRC, the even pixel is taken on the rising edge, and also the
syncs are sampled on the rising edge.  The transmitter wants the syncs
to be "in time" with the data.  That is, de (data enable) is asserted
with the first pixel and is deasserted after the last pixel.  Hsync
and vsync are also managed as usual and get encoded in the DVI TMDS
signal.  I am not aware of DVI using anything other than
negative-assertion h and v sync, but positive may be acceptable as
well.  Aside from the fact that DVI is all digital, it conforms to so
much legacy CRT protocol that it doesn't take much to make the leap.
The only major difference is that analog doesn't generally have a
data-enable (although some DACs will take one that they use to
indicate pedestal).

Thanks!


// 800 X 600 @ 60Hz with a 40.000MHz pixel clock
module sync_const;


I'm going to have a look at your code tomorrow.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to