Timing Question

[Altera_Forum]

Hi everybody, I'm new to these forums.. the community seems helpful. Hopefully someone will have input on my question, and hopefully I can help others.  

 So I'm working on an MAXPLUS7128 SLC84-15 cPLD and am designing a program that works with ADC0831 IC, where simply I make:  -output cs <= '0' to activate the IC,   -make bidirectional data <= '1', to start conversion,   -then I have " IF count < 10 THEN reg(count) <= data " for serial to parallel conversion.   My question about timing is when it comes to the clocking of the IC. I have code which passes clock signal going to the cPLD to an output pin on the cPLD to the IC. Would this create significant propagation delay which could conflict with " IF count < 10 THEN reg(count) <= data " ? More specifically what I am asking is,   When the code looks on data but maybe data is slightly out of sync so it changes slightly after that line of code is called. What would happen?   Sorry for wall of text, I know what I want to know, but I can't word the question properly. Anyways, cheers!

[Altera_Forum]

I am not clear about your issue. is it timing of serial data with its clk? or serial to parallel conversion inside cpld? 

 for serial data out transmission you will need to generate your serial data and its serial clk in same process.The process being clked by another suitable clk.   normally your counting to be at twice serial clk speed. A good practice is make clk transition in the middle of data time slot.    -- on the clked process case count is when 0 => seial_data <= reg_bit(0); serial-clk <= '0'; when 1 => serial_data <= reg_bit(0);serial_clk <= '1'; when 2 => serial_data <= reg_bit(1);serial_clk <= '0'; when 3 => serial_data <= reg_bit(1);serial_clk <= '1';

[Altera_Forum]

Hey, I like that code. Thanks for the suggestion.

[Altera_Forum]

Kaz, this is what my code looks like now: 

  ENTITY adc IS PORT(clk_in: IN BIT; clk_out, cs: OUT BIT; data: INOUT BIT; temperature: OUT BIT_VECTOR (7 DOWNTO 0)); END adc; ARCHITECTURE one OF adc IS BEGIN PROCESS (clk_in) VARIABLE count: INTEGER RANGE 0 to 21; BEGIN IF clk_in = '1' AND clk_in'EVENT THEN count := count + 1; CASE count IS when 1 => cs <= '1'; clk_out <= '0'; when 2 => cs <= '0'; clk_out <= '1'; when 3 => clk_out <= '0'; when 4 => clk_out <= '1'; when 5 => clk_out <= '0'; temperature(7) <= data; when 6 => clk_out <= '1'; temperature(7) <= data; when 7 => clk_out <= '0'; temperature(6) <= data; when 8 => clk_out <= '1'; temperature(6) <= data; when 9 => clk_out <= '0'; temperature(5) <= data; when 10 => clk_out <= '1'; temperature(5) <= data; when 11 => clk_out <= '0'; temperature(4) <= data; when 12 => clk_out <= '1'; temperature(4) <= data; when 13 => clk_out <= '0'; temperature(3) <= data; when 14 => clk_out <= '1'; temperature(3) <= data; when 15 => clk_out <= '0'; temperature(2) <= data; when 16 => clk_out <= '1'; temperature(2) <= data; when 17 => clk_out <= '0'; temperature(1) <= data; when 18 => clk_out <= '1'; temperature(1) <= data; when 19 => clk_out <= '0'; temperature(0) <= data; when 20 => clk_out <= '1'; temperature(0) <= data; when OTHERS => cs <= '1'; END CASE; END IF; END PROCESS; END one; While troubleshooting I notice there is no frequency coming out of clk_out pin. Any suggestions?

[Altera_Forum]

I just ran your code in modelsim and I see the clk_out toggling. Are you sure that you provide a valid clock on the input? 

 I also have some advice about your code:[list][*]You should use std_logic and std_logic_vector types in your code, they provide better options for simulation.[*]You should also manually wrap your counter to make it wrap back to 0. The simulator will complain when you try to reach 22, and the synthesizer will probably generate a 5 bits counter which will roll over every 32 cycles instead of 22.[*]You should also buffer your outputs through signals, your code is not synthesizable in this state.[/list]

[Altera_Forum]

Hello, 

 It turns out I was measuring the wrong pin.. Haha the clk_out is fine.   My input clock is fine, I have created a very stable clock on it previous to this experiment.   I will make sure to change my ports to STD_VECTOR.  I had removed the when 21 case to wrap back to 0 thinking it might help so I'll put it back in.   Could you please expand on your third suggestion about signals? I think this means using temporary variables inside PROCESS, and then assigning the variable to a port at the end of PROCESS.   Other than that I think I need to keep on re-reading the data sheet and simulating, instead of burning.   Thanks

[Altera_Forum]

When you want to synthesize a design with output ports that are changed in a clocked process, you can't directly assign out ports from the process. The synthesizer considers that the signal on the output port needs to be read back by the hardware in order to maintain its state during the clock cycle. There are two ways around this: 

[list][*]declare the port as 'BUFFER' instead of 'OUT'. This is usually considered to be the bad solution (and I agree) because it makes things more complicated (to stay polite) when combining different components. 'BUFFER' is a kind of viral attribute that you need to propagate everywhere in your design when you start using it[*]use an internal signal. Connect that internal signal to the out port outside of the process, and only assign values to that internal signal inside the process[/list]Here is an example of the latter: ARCHITECTURE one OF adc IS SIGNAL cs_buffer: STD_LOGIC; BEGIN cs <= cs_buffer; PROCESS (clk_in) VARIABLE count: INTEGER RANGE 0 to 21; BEGIN cs_buffer <= '1'