"rising_edge(clk)" and delay

[rickman]

On 6/11/2016 3:05 PM, kristoff wrote:

Hi Rick,

On 11-06-16 16:00, rickman wrote:

My question was in the first place intented to get an idea of how to do
syncronous design.

My bad, see below. I think you are doing pretty well.

No problem.


Last week, I talked to somebody who works in a company that does ASIC
design and he said that -althou VHDL is a high-level language- you need
to keep in mind that this all gets turned into hardware.

"always try to understand how the hardware that actually does the job
actually works".

I used to promote this. I think it is useful for sure, but I don't know
it is essential. I was helping a software guy get up to speed on VHDL
and he was able to develop a "Hello, world" program without really
knowing how the hardware would work. He then went on to design the
system his boss needed for a demo to the customer.

I started out thinking you needed a knowledge of gate level logic
principles and an idea of the register level logic you wanted to create.
He showed me these are far from essential. These are very useful when
you wish to optimize a design either for size or speed. But even more
important is familiarity with the tools you are using.

--

Rick C

 

[KJ]

On Saturday, June 11, 2016 at 7:19:52 PM UTC-4, rickman wrote:

Your SPI interface is one of the places where both edges of the clock
*will* be used. When exchanging data externally you can't control the
clock skew enough to use the same clock edge for shifting data out and
shifting data in. So data is clocked out on one edge and in on the
other to assure adequate setup and hold times.

Yes, and SPI is the type of example I had in mind where you might mistakenly think going in that you need to use the SPI Clock as an actual clock signal to clock some register(s), but you don't. SPI clock edges can be determined by sampling with the free running system clock unless the two clocks are close in frequency, which many times they are not. By using the system clock to clock registers rather than SPI clock you avoid clock domain transfers further down the road.

Kevin Jennings

 

[rickman]

On 6/12/2016 10:15 PM, KJ wrote:

On Saturday, June 11, 2016 at 7:19:52 PM UTC-4, rickman wrote:

Your SPI interface is one of the places where both edges of the clock
*will* be used. When exchanging data externally you can't control the
clock skew enough to use the same clock edge for shifting data out and
shifting data in. So data is clocked out on one edge and in on the
other to assure adequate setup and hold times.

Yes, and SPI is the type of example I had in mind where you might mistakenly think going in that you need to use the SPI Clock as an actual clock signal to clock some register(s), but you don't. SPI clock edges can be determined by sampling with the free running system clock unless the two clocks are close in frequency, which many times they are not. By using the system clock to clock registers rather than SPI clock you avoid clock domain transfers further down the road.

I've never done it that way. SPI can be pretty fast and you need a
clock significantly faster to make it work that way. I implement the
shift register as clocked by the SPI clock and then cross the clock
domain with a handshake. Then your internal clock only needs to be fast
enough to receive the data words.

--

Rick C

 

[kristoff]

Hi Rick,


A follow-up on a thread of some month ago



On 11-06-16 21:24, rickman wrote:

A reasonably simple example would be a basic, fixed size UART, say 8
bits, no parity, one stop bit. Design the transmitter and receiver
separately and test by connecting them together and shipping characters
(...)

OK. I did some work on other stuff inbetween, but I finished the UART
sender and UART receiver. I dropped it on my github account:
https://github.com/on1arf/vhdl-exercises

I tested the code not by simulation but with an test setup of a altera
fpga and a mapple mini clone (STM32F103-based).



(The UART receiver does seams to "slip" characters from time to time, so
that is something I need to look at) :-(



I do have two questions:

1/
In uart_receive, there are four signals that are triggered on a positive
or negative edge, so I created four small edge-detection processes.
(nothing special, just compair in signal with the same signal the
previous clock-cycle).


As I use the same code four times over, for me - as a programmer- it
would be logical to create a function or an object for this; but I don't
know how to do this in VHDL.

The problem here is that there is a data (the value of the input signal
the previous clock-cycle) that must be kept between iterations of
calling the function , i.e. a "static vars" in C linguo.

But -as far as I have found in the documentation about VHDL functions-
local signals in a function in VHDL do not maintain state inbetween
iterations and I see no way to define "static" local signals.


As a result, uart_receive.vhd has four edge-detection functions, with
all data stored as "global" data. Note very clean :-(



Now I cannot really image that VHDL does not have a way to store "code"
that maintain state inbetween iterations.

So how do you do this?



2/
I am now working on a FIFO-buffer to make the UART_receiver more robust.

Do I need to add the FIFO buffer in the same VHDL-file (the same
architecture) as the UART_receiver code; or is there a way to store the
fifo-buffer VHDL-code in a seperate file.

Then how do I "include" and "call" the FIFO vhdl-code in the
uart_receive circuit?



> Just a thought.

A very interesting exercise, I must say.


I am now working on the 4 byte FIFO buffer for the UART. After that,
I'll try the SPI stuff.



Cheerio!
Kr. Bonne.

 

[rickman]

On 7/19/2016 5:59 PM, kristoff wrote:

Hi Rick,


A follow-up on a thread of some month ago



On 11-06-16 21:24, rickman wrote:
A reasonably simple example would be a basic, fixed size UART, say 8
bits, no parity, one stop bit. Design the transmitter and receiver
separately and test by connecting them together and shipping characters
(...)


OK. I did some work on other stuff inbetween, but I finished the UART
sender and UART receiver. I dropped it on my github account:
https://github.com/on1arf/vhdl-exercises

I tested the code not by simulation but with an test setup of a altera
fpga and a mapple mini clone (STM32F103-based).



(The UART receiver does seams to "slip" characters from time to time, so
that is something I need to look at) :-(



I do have two questions:

1/
In uart_receive, there are four signals that are triggered on a positive
or negative edge, so I created four small edge-detection processes.
(nothing special, just compair in signal with the same signal the
previous clock-cycle).


As I use the same code four times over, for me - as a programmer- it
would be logical to create a function or an object for this; but I don't
know how to do this in VHDL.

The problem here is that there is a data (the value of the input signal
the previous clock-cycle) that must be kept between iterations of
calling the function , i.e. a "static vars" in C linguo.

But -as far as I have found in the documentation about VHDL functions-
local signals in a function in VHDL do not maintain state inbetween
iterations and I see no way to define "static" local signals.


As a result, uart_receive.vhd has four edge-detection functions, with
all data stored as "global" data. Note very clean :-(



Now I cannot really image that VHDL does not have a way to store "code"
that maintain state inbetween iterations.

So how do you do this?

Two ways to do it. One is to create an entity which contains the code
as well as the signal declarations of any signals you need for internal
storage. Then the entity is instantiated four times.

Or you can use a procedure call. A procedure is sequential code and you
can declare variables which *can* remember state between invocations if
coded so they are used before being set. The variable can only be
"seen" from outside of the procedure call by assigning its value to a
signal in the parameter list.

You might be able to use a function rather than a procedure if it only
needs to return a single item (which can be an array or record).

2/
I am now working on a FIFO-buffer to make the UART_receiver more robust.

Do I need to add the FIFO buffer in the same VHDL-file (the same
architecture) as the UART_receiver code; or is there a way to store the
fifo-buffer VHDL-code in a seperate file.

Then how do I "include" and "call" the FIFO vhdl-code in the
uart_receive circuit?

Separate entities can be defined in separate files or the same file.
Functions, procedures and data types can be defined in libraries.
Libraries are included with "use" statements.

Just a thought.

A very interesting exercise, I must say.


I am now working on the 4 byte FIFO buffer for the UART. After that,
I'll try the SPI stuff.

--

Rick C