timing ...

[Amit]

Hello group,

Is there any good resource or book to learn timing? or maybe there is
a method that I can use.

Your response is appreciated.

Regards,
Amit

 

[kennheinrich]

Hello group,

Is there any good resource or book to learn timing? or maybe there is
a method that I can use.

Your response is appreciated.

Regards,
Amit

You could try Einstein's "Relativity: The Special and the General
Theory". It's cheap (available in paperback for about $15) and written
at a fairly introductory level. It lays out the basic framework of
time as it is understood by most modern physicicsts.

But seriously, your question is so broad that you would best ask a
more specific question.

- Kenn

 

[Mike Treseler]

Is there any good resource or book to learn timing? or maybe there is
a method that I can use.

http://www.altera.com/literature/hb/qts/qts_qii53004.pdf

 

[Amit]

http://www.altera.com/literature/hb/qts/qts_qii53004.pdf

Thanks to both of you for the answers. Specially to Mike. Ok, Kenn let
me be more clear you are right. I'm in a transition from software to
digital design field and of course I'm not that familiar with terms
yet and I apologize for using some wrong or very general terms.

Now, in this learning process I have given a project to read some
music files which seemed doable and have done it by now (except some
minor changes I have to apply). Next, step is reading the raw data
(music) and sending them to a Wolson WM8731 CODEC and FIFO. Here is my
nightmare; This CODEC has some timing theory which sounds very hard
page 15 at http://www.wolfsonmicro.com/uploads/documents/en/WM8731.pdf.

I have few days to understand this timing thing and implement it using
VHDL in Quratus II. I have no idea how to start it. I would love to
learn this concept and impelement it so desperately looking for a way
to understand how these things work.

It seems the pdf sent by Mike is helpful and I will look at it for
sure. Once again thanks and I will appreicate it if somebody could
help.

Thanks!

 

[KJ]

Now, in this learning process I have given a project to read some
music files which seemed doable and have done it by now (except some
minor changes I have to apply). Next, step is reading the raw data
(music) and sending them to a Wolson WM8731 CODEC and FIFO. Here is my
nightmare; This CODEC has some timing theory which sounds very hard
page 15 at http://www.wolfsonmicro.com/uploads/documents/en/WM8731.pdf.

I have few days to understand this timing thing and implement it using
VHDL in Quratus II. I have no idea how to start it. I would love to
learn this concept and impelement it so desperately looking for a way
to understand how these things work.

You have your work cut out for you then. The fundamental ideas you need to
grasp are
1. Nothing happens instantaneously, there will always be some delay/skew
between any two signals
2. No delay/skew is completely predictable so there will always be some
uncertainty in the actual device delay
3. In order to work properly, most parts have some timing requirements that
need to be met.

The spec sheets defines the parameters for a particular device. An example
of #1 and #2 in your referenced spec is Figure 2 where the waveform and
parameter table define Tcop as being the delay from the input signal
'XTI/MCLK' to the output signal 'CLKOUT'. This delay has a minimum of 0 ns
and a maximum of 10 ns. What this means is that an edge on CLKOUT will be
skewed from an edge on XTI/MCLK by anywhere from 0 to 10 ns. Maybe you care
about that skew, maybe you don't, it is simply saying what to expect from
the device. This particular type of parameter is generally referred to as a
propogation delay.

Figure 4 shows examples of #1, #2 and #3. Parameters Tdl and Tdda define
the skew between the outputs ADCLRC, DAD/LRC, ADCDAT relative to the falling
edge of BCLK. Just like the Figure 15 example it is simply stating what the
part will do and is an example of #1 and #2. Since the output delays are
referenced to what appears to be a clock, this type of parameter is
generally referred to as 'clock to output' delay.

The parameters Tdst and Tdht on that same figure are an example of #3, which
is a requirement that you must meet in order for the part to work correctly.
That figure implies that the input DACDAT is an input that gets sampled on
the rising edge of BCLK. Again, real parts are not able to sample things
instantaneously, the thing that is being sampled (in this case DACDAT) must
be stable for some period of time (in this case Tdst) before the rising edge
of the thing that samples it (in this case BCLK) and must hold it stable for
some period of time after that rising edge of BCLK (in this case Tdht). In
order for the part to work correctly, whatever it is that connects to these
inputs must meet these requirements otherwise there is (in general) no way
to know what the part will do. Those two parameters are generally referred
to as setup time (Tdst) and hold time (Tdht).

It's also important to pay attention to the test conditions that are listed
with each figure. 'Most' of the time, those conditions are similar enough
to what you'll actually have in your design that the listed numbers will be
applicable, but not always and strictly speaking all those timing parameters
only apply to that test condition.

You'll also want to guard your design somewhat and leave a few ns of margin
so that if you have a requirement to have the signal stable 10ns before some
clock that the signal arrives there maybe 12-15 ns or so before. There are
a lot of electrical things that have to go on to get that signal there, and
most of them don't make the signal look like the nice square-ish waves shown
in a timing diagram.

Good luck.

Kevin Jennings

 

[Mike Treseler]

I have few days to understand this timing thing and implement it using
VHDL in Quratus II. I have no idea how to start it. I would love to
learn this concept and impelement it so desperately looking for a way
to understand how these things work.

Start with simplified prototypes and work them
through description and simulation. Have a look on
the rtl viewer. Repeat. It will take a few months
more than a few days. Good luck.

-- Mike

 

[kennheinrich]

Start with simplified prototypes and work them
through description and simulation. Have a look on
the rtl viewer. Repeat. It will take a few months
more than a few days. Good luck.

-- Mike

Mike and Kevin are bang on with their advice. But before you start
thinking all is lost... let's assume that you're just trying to hack
something up for your own home use, and the clock speed is fairly low.
Then you can usually cut a few corners and not get too hung up on
timing. For a good chunk of chips, you can look at the data sheet and
see that the timing looks good if you either send data on rising or
falling edge of your main clock, and you can usually latch returned
data on the rising or falling edge of the same clock. You'll still
need to understand prop delay out of your FPGA, but it's a simplifying
case. As long as you keep the messy stuff (front edge/back edge
clocks, or extra setup & hold requirements that you might apply to as
timing constraints to the place & route tools) isolated from the core
of your main design, you can usually separate your design into easier-
to-manage sections. You can debug the core state machines in RTL
through simulation, and then integrate the interface pins to the core
logic afterwards. Of course, having a scope or an embedded logic
analyser will help a lot, too.

Disclaimer: if you get *paid* to design logic, you certainly deserve
all the grief that will come your way should you cut corners on
timing

Just try it out, hopefully you'll learn something useful & have some
fun.

- Kenn

 

[Amit]

Mike and Kevin are bang on with their advice. But before you start
thinking all is lost... let's assume that you're just trying to hack
something up for your own home use, and the clock speed is fairly low.
Then you can usually cut a few corners and not get too hung up on
timing. For a good chunk of chips, you can look at the data sheet and
see that the timing looks good if you either send data on rising or
falling edge of your main clock, and you can usually latch returned
data on the rising or falling edge of the same clock. You'll still
need to understand prop delay out of your FPGA, but it's a simplifying
case. As long as you keep the messy stuff (front edge/back edge
clocks, or extra setup & hold requirements that you might apply to as
timing constraints to the place & route tools) isolated from the core
of your main design, you can usually separate your design into easier-
to-manage sections. You can debug the core state machines in RTL
through simulation, and then integrate the interface pins to the core
logic afterwards. Of course, having a scope or an embedded logic
analyser will help a lot, too.

Disclaimer: if you get *paid* to design logic, you certainly deserve
all the grief that will come your way should you cut corners on
timing

Just try it out, hopefully you'll learn something useful & have some
fun.

- Kenn

Thanks to everybody for helping me to start understanding the concept
BUT I have questions for each one of you and will appreciate it if you
give a response.

__________________
Questio for Kevin:

It was so nice that you went thru those pages and explained them to
me. I followed your statements as I was going thru those pages. Now, I
think I know what I should do (after reviewig these again). My
question for you is "What is the next step? after understanding the
timing/delays ?" let's say I want to control the clock and get the
output expected in those figures using VHDL.
What should I do?
How can I do that?
Is there any samples? do I need to create an Entity with the same
input/output ports and try to get an output exactly to those figures
on page 15?


__________________

Questio for Mike:
through description and simulation".

What prototypes do you mean? can you give me a sample?


__________________

Question for Kenn:


Thanks to all.

Regards,
Amit

 

[Mike Treseler]

What prototypes do you mean?

I would start with a vhdl entity to write data to the
control registers that control the volume.

can you give me a sample?

My coding style is based on this synchronous process:

---------------------------------------------------------
-- Process Template -- Always exactly the same:
---------------------------------------------------------
begin -- process template
if reset = '1' then
init_regs;
elsif rising_edge(clock) then
update_regs;
end if;
update_ports;
end process sync_template;
end architecture synth;

details here:
http://home.comcast.net/~mike_treseler/

 

[KJ]

Questio for Kevin:

It was so nice that you went thru those pages and explained them to
me. I followed your statements as I was going thru those pages. Now, I
think I know what I should do (after reviewig these again). My
question for you is "What is the next step? after understanding the
timing/delays ?" let's say I want to control the clock and get the
output expected in those figures using VHDL.
What should I do?

Well first you have to understand functionally how the part works and
what the various input and output signals even do. As a rough guide,
every input to the device you're trying to control (i.e. the 'Wolson
WM8731 CODEC and FIFO') will come from an output on your FPGA.
Similarly, every output of your device will most likely connect to an
input to your FPGA. How the FPGA would connect to anything else in
your system, I haven't a clue since all you said earlier is "I have
given a project to read some
music files..." so presumably you already know how you're getting
those music files into whatever device it is (the FPGA?) that then
connects to the CODEC, but maybe your design isn't worked out even
that much. In any case, you're likely trying to move bytes of data
from somewhere into the CODEC so you'll need to understand what format
the CODEC wants those bytes of data and how you need to control the
CODEC in order to accomplish that task.

How can I do that?

1. Study the entire data sheet, not just the timing diagrams.
2. Come up with a VHDL design for the FPGA that will control the
CODEC.
3. Come up with a VHDL model for the CODEC. Maybe you can get it from
the supplier, maybe you'll have to write it yourself based on your
understanding of the part that was gleaned from step #1. If you don't
have the understanding to write such a model yourself, then you also
most likely don't have the understanding to successfully complete step
#2.
4. Create a testbench that connects the FPGA to the CODEC (and
whatever it is that will get the music files into the FPGA in the
first place) and simulate the system. Once you can simulate correctly
and move data from the 'music files' all the way through the system
into the CODEC, then you're probably ready to try it out on a real
board. Until that time, you're better off debugging in simulation
(it's much faster to find/fix errors).

Is there any samples? do I need to create an Entity with the same
input/output ports and try to get an output exactly to those figures
on page 15?

You're trying to get things to meet requirements not match some
figure. For example, if some signal has a 10ns minimum setup time
requirement, then that does not mean you need to get the signal there
precisely 10ns before, anything larger than 10ns would do.

Things to consider that cause heartahces are signals that have both
setup time and non-zero hold time requirements (I think your CODEC had
those). One usually relatively easy to meet such requirements if the
clock isn't running too fast is to send those signals on the opposite
edge of the clock that the device is looking for them. That way
you're guaranteed that the signals are stable both before and after
the point where the device needs them since they will be there
nominally 1/2 clock cycle both before and after the sampling edge.

If you're asking for a completed design to do all of this though, you
likely won't find it by posting questions in a newsgroup without a
contract to pay for such design services.

Kevin Jennings

 

[Martin Thompson]

1. Study the entire data sheet, not just the timing diagrams.
2. Come up with a VHDL design for the FPGA that will control the
CODEC.
3. Come up with a VHDL model for the CODEC. Maybe you can get it from
the supplier, maybe you'll have to write it yourself based on your
understanding of the part that was gleaned from step #1. If you don't
have the understanding to write such a model yourself, then you also
most likely don't have the understanding to successfully complete step
#2.

Of course, if you write it yourself, any *mis*understandings will be
duplicated in the FPGA and the CODEC model, so the simulation will
work fine. And real life won't!

Not that I've ever had that problem, honest

Cheers,
Martin

 

[KJ]

Of course, if you write it yourself, any *mis*understandings will be
duplicated in the FPGA and the CODEC model, so the simulation will
work fine.  

That can be true but I've also found that I tend to have a totally
different mindset when I'm writing the code for the model of a
'something' than I do when I'm writing the code for the control of
that 'something'. That difference tends to cut down on some of the
duplication of misunderstandings. In any case, demonstration in a
simulation environment of correct operation as you understand the part
to operate is a minimal first hurdle that one should clear before
wasting time debugging real parts...unless the boss sees time spent
simulating as not being productive (although it is) and time spent
with scope/logic analyzer probes in hand as being productive (which
it's not when it gets excessive).

And real life won't!

That's when the learning lesson kicks in about making the effort to
model the part sufficiently...cuz that's when the boss is ticked
because you assured him/her that the design would work and now it
'taint. That learning lesson will also sharpen your mind about what
types of things to include in the model and which can be shortcut
since modelling the complete behavior of a complex part on your own is
time wasted as well.

Not that I've ever had that problem, honest

Me either...but I have had to dumb down my wonderful models to match
the obviously insane, ridiculous behavior of some parts ;-)

KJ

 

[Amit]

That can be true but I've also found that I tend to have a totally
different mindset when I'm writing the code for the model of a
'something' than I do when I'm writing the code for the control of
that 'something'. That difference tends to cut down on some of the
duplication of misunderstandings. In any case, demonstration in a
simulation environment of correct operation as you understand the part
to operate is a minimal first hurdle that one should clear before
wasting time debugging real parts...unless the boss sees time spent
simulating as not being productive (although it is) and time spent
with scope/logic analyzer probes in hand as being productive (which
it's not when it gets excessive).


That's when the learning lesson kicks in about making the effort to
model the part sufficiently...cuz that's when the boss is ticked
because you assured him/her that the design would work and now it
'taint. That learning lesson will also sharpen your mind about what
types of things to include in the model and which can be shortcut
since modelling the complete behavior of a complex part on your own is
time wasted as well.


Me either...but I have had to dumb down my wonderful models to match
the obviously insane, ridiculous behavior of some parts ;-)

KJ

No Kevin,

That's not for money I'm still learning it. Anyway, I have one
question for you guys. In the page 15 which explains the slave mode I
see several signals and as far as I understand there must be two ways:

1) simulation using counters
2) simulation base on State Machine such as MOORE.

Please correct me if I'm wrong.

Now, do I need 4 counters here or should I consider BCLK (Bit Clock)
as well?

Thanks.

 

[Martin Thompson]

That can be true but I've also found that I tend to have a totally
different mindset when I'm writing the code for the model of a
'something' than I do when I'm writing the code for the control of
that 'something'. That difference tends to cut down on some of the
duplication of misunderstandings.

Yes, I think that's true, but it's something you develop over time.
My early TB models tended to look very synthesisable, which usually
means more like the "other end". Nowadays they're much smaller and
full of weird software-like things, which scares traditional HDL
people

In any case, demonstration in a simulation environment of correct
operation as you understand the part to operate is a minimal first
hurdle that one should clear before wasting time debugging real
parts

Yes!

Of course, occasionally, you think "That's a trivial piece of code,
I'll just stick it in the hardware and off we go"... Then you go back
and simulate it when it doesn't work and you've no idea why

<snip

Me either...but I have had to dumb down my wonderful models to match
the obviously insane, ridiculous behavior of some parts ;-)

I like that description!

Cheers,
Martin