Synchronous Serial Port design

[adriana]

Hello everybody,

I need to design a Synchronous Serial Port of a PIC processor that
works in SPI mode.

You can find the datasheet here:
http://ww1.microchip.com/downloads/en/DeviceDoc/31015a.pdf

This SSP have some components and I'm trying to write an RTL
(components) model.

I have 1 shift register, 1 buffer register,2 mux and others simple
gates.

I just write models for all these components but I don't
know how to represent 2 registers (8 bits) that are used like "status
register" and "controller register".

Supposed that I will use 2 8-bit latches, how can I link these 2
components to the others ? I mean that
in the block diagram (figure 15-1) there isn't any "arrows" that link a
component to these registers so I don't know what signals use because
the scope of these 2 registers is only to controlling behaviour of the
serial port.

I hope I'm clear enough (sorry for my poor english).

Thank you very much,

Adriana (Italy)

 

[Ralf Hildebrandt]

adriana wrote:

I need to design a Synchronous Serial Port of a PIC processor that
works in SPI mode.

You can find the datasheet here:
http://ww1.microchip.com/downloads/en/DeviceDoc/31015a.pdf

I've done the the successor, the MSSP (SPI and I2C, both Master and
Slave) some time ago for my company. If you are interestend in the
IP-core - mail me. ;-)

This SSP have some components and I'm trying to write an RTL
(components) model.

I have 1 shift register, 1 buffer register,2 mux and others simple
gates.

I just write models for all these components but I don't
know how to represent 2 registers (8 bits) that are used like "status
register" and "controller register".

SSPCON and SSPSTAT?

Supposed that I will use 2 8-bit latches, how can I link these 2
components to the others ? I mean that
in the block diagram (figure 15-1) there isn't any "arrows" that link a
component to these registers so I don't know what signals use because
the scope of these 2 registers is only to controlling behaviour of the
serial port.

Schematics do not tell you everything. The are drawn to give you an
overview. A lot of things are omitted and sometimes schematics contain
errors, because sometimes schematics are not drawn by the designer of
the component or are drawn long time ago and changes in the component
are not updated in the schematic.

SSPCON and SSPSTAT control and monitor something in the SSP component.
Every bit has a very special purpose. Each purpose is defined in the
text - not in schematics. E.g. WCOL is modelled in a way like this:

process(reset,write)
begin
if (reset='1') then
WCOL='0';
elsif rising_edge(write) then
if (write_to_SSPBUF='1') then
WCOL<='1';
elsif (write_to_WCOL='1') then
WCOL<=data_in(7);
end if;
end if;
end process;
-- flipfop-variant (latches are possible, too)

This was an idea of the bit for data-input and the special purpose of
this bit. Remeber, that you need a model for data output, too.

The other bits may be more complex. Just read the text of the document
and figure their purpose out.
Hint: Model every bit of SSPSTAT and SSPCON individually. They are very
different, and therefore a description inside one process will become a
mess.

Ralf

 

[Ralf Hildebrandt]

Ralf Hildebrandt wrote:

There is a functional error in the description of WCOL:

process(reset,write)
begin
if (reset='1') then
WCOL='0';
elsif rising_edge(write) then
if (write_to_SSPBUF='1') then -- error
WCOL<='1';
elsif (write_to_WCOL='1') then
WCOL<=data_in(7);
end if;
end if;
end process;

Corrected:

if (write_to_SSPBUF='1' AND transmission_active='1') then


Ralf

 

[adriana]

Hi Ralf,
thank you for reply,

I've done the the successor, the MSSP (SPI and I2C, both Master and
Slave) some time ago for my company. If you are interestend in the
IP-core - mail me. ;-)

Wow.. I've found the right man!
I'm really new to VHDL , this is my assignment exam at university..

SSPCON and SSPSTAT?
Yes, exactly

SSPCON and SSPSTAT control and monitor something in the SSP component.
Every bit has a very special purpose. Each purpose is defined in the
text - not in schematics. E.g. WCOL is modelled in a way like this:

Ok I've understood this and I know the purpose for every bit (for the
SPI mode
few bits are used) .

I need to understand what you mean for "Model every bit of SSPSTAT and
SSPCON individually".
For example, where I will put the WCOL modeling that you suggest me ?

What I'm doing ,until now,is to write a model (in separated vhdl files)
for every component.
For example for the mux, I wrote:

library ieee;
use ieee.std_logic_1164.all;

entity sspmux is
port(
sel: in std_logic_vector(1 downto 0);
in1,in2: in std_logic;
mux_out: out std_logic
);
end sspmux;

architecture behavioral of sspmux is
begin
process (sel, in1, in2)
begin
case sel is
when "00" => mux_out <= in1;
when "01" => mux_out <= in2;
when others => null;
end case;
end process;
end behavioral;


and so on for the other components .. finally I would like to write the

architecture body with the components declaration and the signal
corresponding
to the connections.

Using this approach where I will put the description of every
control/status bits ?
(i.e where you define WCOL ?)

This was an idea of the bit for data-input and the special purpose of
this bit. Remeber, that you need a model for data output, too.

Can you also explain better to me what you mean for data-input and
output model?

Sorry for so many questions .. be patient with me

Adriana

 

[Ralf Hildebrandt]

adriana wrote:

I need to understand what you mean for "Model every bit of SSPSTAT and
SSPCON individually".

Put every bit into a signle process.

Every bit has very special reset / set conditions and obviously special
synchronous behavior.

For a while forget, that some of these bits together form the vector
called SSPSTAT. Threat every bit beeing unique and collect all bits
somewhere like

SSPCON<=WCOL & SSPOV & SSPEN & CKP & SSPM3 & SSPM2 & SSPM1 & SSPM0;

if you want.

For example, where I will put the WCOL modeling that you suggest me ?

What I'm doing ,until now,is to write a model (in separated vhdl files)
for every component.
For example for the mux,...

So you would produce one component for every flipflop or group of
combinational logic (e.g., adder, mux...). I guess, having so many
components makes a design extremly bad readable.

If I remember right (I'm at home and don't have the source code at hand)
I put everything into one architecture. Such peripheral components, like
the (M)SSP have a lot of connections between the flipflops.

and so on for the other components .. finally I would like to write the

architecture body with the components declaration and the signal
corresponding
to the connections.

Remember, that this makes it harder for synthesis tools to optimize,
because they have to break the hierarchy. If you do it so, you do
synthesis almost manually. Give the synthesis tool a try - they are
quite smart. ;-)

Furthermore if you put everything into one architecture it is very easy
to read the value of a signal, e.g. you can write everywhere
....
if (WCOL='1') then
....

The (M)SSP is not that big, that the VHDL-file will become too big and
unreadable if you just put everything into one component. If you locate
a group of logic and registers, that interact with only a few signals
with the other parts, feel free to put this group into a subcomponent.

This was an idea of the bit for data-input and the special purpose of
this bit. Remeber, that you need a model for data output, too.


Can you also explain better to me what you mean for data-input and
output model?

WCOL is accessible via the data bus. It can be read and written. Writing
to WCOL I have shown in my example. (data_in is the data bus from the
CPU for RAM and peripheral component access.)

Reading a value from a component is not very difficult: If there is a
read access and the address at the address bus matches the address of
SSPCON then drive WCOL to data_out(7). (data_out is the data bus to the
CPU for RAM and peripheral component access.)

How to drive data_out depends on the data bus model you use in your
microcontroller (e.g. OR-bus, AND-bus, tri-state-bus).


Ralf

 

[adriana]

Ok Ralf,
now it's clear, thank you.

Seeing that I'm in trouble with the RTL model I will try to follow your
approach
for a behavioral model.

Regarding the data bus model was not so clear because I need only to
implement a model for the SSP without enter in detail about the
connections
with others peripheral component (or with the internal bus of the PIC).

I mean that at the moment I would like only to implement this:

SSP has like input:

- SDI (serial input)
- SS (to enable select mode)
- reset
- SCK (clock)

and for output:

- SDO (serial output)

behaviour:

receiving (all in one process):

0) The SSP is initializated (so using your approach I will set every
single bit in the correct status)
1) The bits enter in the SSP in serial way trough the SDI input.
2) They goes to the SSPSR (I will use a vector to represent the SSPSR
shift register) that shifts on the SCK clock.
3) After 8 bits (1 word) in the SSPSR, the byte is moved to the SSPBUF
(other vector)
4) The control bits are setted following the requirements

Only this! (I will think later to the sending process)

So I don't' think that I have to use a data bus for this , it's correct
?
How can I realize the point 1) ?
I need also to write a test bench for this model, can I use this to
realize the point 1) ?

Many thanks,
Adriana

 

[Ralf Hildebrandt]

adriana wrote:

Regarding the data bus model was not so clear because I need only to
implement a model for the SSP without enter in detail about the
connections
with others peripheral component (or with the internal bus of the PIC).

O.k. - but I guess it will be very handy, if do not ignore this. I will
tell you more later in the posting.

0) The SSP is initializated (so using your approach I will set every
single bit in the correct status)
1) The bits enter in the SSP in serial way trough the SDI input.
2) They goes to the SSPSR (I will use a vector to represent the SSPSR
shift register) that shifts on the SCK clock.
3) After 8 bits (1 word) in the SSPSR, the byte is moved to the SSPBUF
(other vector)
4) The control bits are setted following the requirements

Only this! (I will think later to the sending process)

Reception and transmission is done together with SPI.

So I don't' think that I have to use a data bus for this , it's correct
?

How do you want to test your design?

It is very nice to connect 2 (M)SSP modules to the microcontroller,
configure one as master and one as slave and let them communicate. You
can write all tests in assembler or even in C which makes it highly
flexible.
If you just implement the communication core without the interface to
the microcontroller, you have to think about a different test strategy.
There must be some good way to do this, but testing the component in a
real-life-environment together with the microcontroller uncovers bugs
very well.

How can I realize the point 1) ?

This is a simple shift register - a chain of flipflops, that send their
output to the next flipflop.

More complex is the data interface to this shift register (=SSPBUF),
because you can write to it via the data bus AND it's function is the
mentioned shift register. But delay this problem a little bit until
other parts are more clear.

I need also to write a test bench for this model, can I use this to
realize the point 1) ?

Yes you can, but as I wrote: You don't need a VHDL testbench, if you
test your design in the microcontroller environment (=software testbench).

Ralf