Process variable setup times and propogations

The change you show should not have made any difference. Post the complete process. Something else is going on.

Try changing if(FIFOhead = 3) to if(FIFOhead >= 3)

-- Mike Treseler

process. Something else is going on.

Thanks for the reply, Mike - here's the whole reciever UART process I'm currently synth'ing... I started with a basic UART design from freecores.org and wound up rewriting a bunch of it in order to process things like break conditions and the like, as well as adding in the small FIFO to help with handling data flow. As written below, the UART seems to function pretty much normally when synthesized into the chip. However, beyond the problem I origionally mentioned (the FIFOhead not seeming to update right away) this UART also seems to have the quirk of occasionally letting two of the same received byte slip thru when data is constantly streaming in.

Unfortunatly this system contains two seperate clocks - one which is devided down to run the UART at standard baud rates, and another which drives the main chunk of the system which reads the recived bytes from the UART. It seems that on occasion (and this is verifiable on a logic analyzer) the clocks seem to line up such that status data is not read correctly, and the UART is somehow being read twice in quick succession.

Do I need to include a higher-level syncronization method to ensure the two clocks don't cause issues when inevitably lining up such that one is reading data controlled by the other, whilst the data is in the middle of a transition?

I've played with a couple possible solutions, but nothing seems to work with the double-reads. This seems like a nice simple recieving UART, but I'm stumped. Any ideas?

Regards,

-- Matt

................ entity RxUnit is port ( Clk : in Std_Logic; -- system clock signal Reset : in Std_Logic; -- Reset input Enable : in Std_Logic; -- Enable input ReadA : in Std_logic; -- Async Read Received Byte RxD : in Std_Logic; -- RS-232 data input RxAv : out Std_Logic; -- Byte available DataO : out Std_Logic_Vector(7 downto 0); -- Byte received Break : out Std_Logic; -- Break Detected Debug : out Std_Logic); -- debug end entity;

architecture Behaviour of RxUnit is signal RReg : Std_Logic_Vector(7 downto 0); -- receive register signal ReadS : Std_Logic; -- Synchronised load signal

component synchroniser is port ( C1 : in Std_Logic; -- Asynchronous signal C : in Std_Logic; -- Clock O : out Std_logic);-- Synchronised signal end component;

-- the FIFO type FIFOarraytype is array (integer range 0 to 4) of std_logic_vector(8 downto 0); signal FIFO:FIFOarraytype;

begin

-- Synchronise Read on Clk SyncLoad : Synchroniser port map (ReadA, Clk, ReadS); --Busy

process. Something else is going on.

and

devided

line

the two

work with

stumped.

frame

on read edge

one break is

I agree, something else may be going on.

Be aware that if : a) this is all within a single process, and b) Fifohead is a signal not a variable, the assignment of the new value to Fifohead is postponed to the end of the process (or explicit Wait) thus Fifohead will have the old value at the point of the assignments to Fifio(Fifohead). This MUST be the case to avoid race conditions within clocked processes, as a little thought will show.

However, since you use numeric constants 8, 7 downto 0 here, I don't THINK this is the problem, unless it is a tools bug.

- Brian

Quirks like this smell like a synchronization problem. Consider using the synchronous template for all synth code.

You have identified and verified a synchronization problem.

No. Use only only the faster clock as a clock. Inputs including former clocks are all synched with two dflops and become inputs that never appear in a sensitivity list.

Change to

RxProc : process(Clk,Reset)

and watch the other inputs events synchronously.

-- Mike Treseler