Using FPGA to map I/Os into address space

[Altera_Forum]

Hello All, 

I am working on a project to implement a simple mapping of several control and status I/Os from various chips into certain address space for a MCU to read/write. I wrote the code in VHDL. Simulation suggests that it is working ok, but I feel it's not a very well written piece of code..The read/write operation is done via a FSM (because the FPGA has to generate the correct control signals to the MCU to terminate the read/write)...  I am posting it here, maybe someone can take a look and let me know if there's any improvement I can use?  Many thanks and have a nice weekend!   BTW..Is my implementation of the FSM a good practice? I use three processes..The first one is simply to advance state machine on the rising edge of clk..The second one determines next state based on input and current state. The third one, generate the output on the rising edge of clk...In Altera's Quartus II Handbook (and several other places), it seems that people combaining second and third process together. Is there a advantage that way? I'd like to make my code clear..plus, the third process gives me the freedom to choose whether I can have my output on the rising edge or falling edge..

[Altera_Forum]

--- Quote Start ---   Is my implementation of the FSM a good practice? I use three processes..The first one is simply to advance state machine on the rising edge of clk..The second one determines next state based on input and current state. The third one, generate the output on the rising edge of clk...In Altera's Quartus II Handbook (and several other places), it seems that people combaining second and third process together. Is there a advantage that way? I'd like to make my code clear..plus, the third process gives me the freedom to choose whether I can have my output on the rising edge or falling edge..  --- Quote End ---     Hi,   I have always been against the use of anything more than one process for any state machine. Books and tutors may say anything they want but let them come and do the work with deadlines...it is perfectly possible to have just one process FSM so why bother about having excessive code and its problems. If you want to change clk edge then you can just do that separately using a further set of registers.   I already notice that your second process is not right, you may get latches, your sensitivity list contains only the state machine(SC) and not all inputs read inside.

[Altera_Forum]

Abot the FSM, isn't even Altera Quartus II handbook suggesting a FSM of two processes?  

For my code, yes I got warning saying that I have input signals reading inside a process, but not in my sensitivity list. But it doesn't warn me that latches are used for that reason. Also, if you have something like a maped IO. You could have many many input sigals. Should I include all of them in the sensitivity list? Because it is not necessary to trigger the process whenever any input signal change state. Rather, it's the external MCU read/write should trigger the process.. Thanks for answering     --- Quote Start ---  Hi,   I have always been against the use of anything more than one process for any state machine. Books and tutors may say anything they want but let them come and do the work with deadlines...it is perfectly possible to have just one process FSM so why bother about having excessive code and its problems. If you want to change clk edge then you can just do that separately using a further set of registers.   I already notice that your second process is not right, you may get latches, your sensitivity list contains only the state machine(SC) and not all inputs read inside.  --- Quote End ---  

[Altera_Forum]

I always use one process. It is easy, readable, debuggable and quick. 

You have the choice to use 2 or 3 processes but you answered yourself...how would you insert all that long sensitivity list. The rule of comb. process is strict in that the sensitivity list must contain all signals read inside the process and that all assignments to a signal are defined. I have always used one process even for the most complex job. Imagine your module has 3 FSMs each with 3 processes => 9 processes overhead. I can't handle that.

[Altera_Forum]

As often mentioned, missing signals in sensitivity list are mainly a problem with simulation tools as ModelSim, but don't affect synthesized logic usually. 

 Cause the combinational process has no other output signal than NS, it's no infering latches to my opinion, it's usual FSM style so far.  As another point, we simply have to assume, that the interface is cooperating correctly with coldfire bus signals, but we can't check it without knowing it's timing and configuaration in detail.

[Altera_Forum]

--- Quote Start ---  As often mentioned, missing signals in sensitivity list are mainly a problem with simulation tools as ModelSim, but don't affect synthesized logic usually.   Cause the combinational process has no other output signal than NS, it's no infering latches to my opinion, it's usual FSM style so far.   As another point, we simply have to assume, that the interface is cooperating correctly with coldfire bus signals, but we can't check it without knowing it's timing and configuaration in detail.  --- Quote End ---     Hi FvM,   I am used to terms like "usually" or "mainly" in medical books when there is so much doctor's uncertainty. I am sure electronic design wouldn't absorb them.

[Altera_Forum]

Ok, I agree that usually is a vague statement. More precisely: I never experienced a missing entry in sensitivity list having any effect on synthesis results. Thus I assume, that they are generally ignored in synthesis. This is also according to my understanding of a HDL compiler's operation. Do you know of a contradicting case? 

 On the the other hand, Quartus is always issuing warnings on missing sensitivity list signals. This may be reason enough, to complete them, possible usage of functional simulator another.

[Altera_Forum]

My "gut-feeling" is that the completed sensitivity list "may" not "usually" have effect on synthesis but on simulation, I don't have any explanation why the compiler tool makers have led to this discrepancy... 

I -for one- will never go against the "tool rules" because if the Helicopter crash investigators found out(from my fellows ofcourse) I could end up in jail or pay a hefty fine. self-defense design considerations is vital in saftety critical applications

[Altera_Forum]

Any other suggestions towards my code? How about the fact that the IOs are asynchronous input. I am not taking any precautions because they don't change 'that' often. They report the status of some other device or some control signals to these devices. Any problem with that? In my simulation, there's some delay between when the register value is set and the corresponding IO lines change reflecting the change in register. I guess this is because I did't fully constrain the design. If to properly constrain the design, what timing constrain do I need besides the obvious 80MHz input clock signal from coldfire? 

Thanks  Also about the FSM. To keep the clairty of the code, I prefer to keep the three processes structure. Therefore I am little bit concern about possible racing condition. I have the first process advancing the FSM on the rising edge of clock. However, my third process of the FSM generating the outputs based on the CURRENT STATE also updating on rising edge. Wouldn't this create potential race condition for me? The only way I see to solve this is to use a falling edge fir one of the two processes. Is it so? If so, it looks like some of the Dffs launching edge and latch edge are inverted of each other, resulting only half the clock in betwen. This create problem for me. Anyone can explain to me?

[Altera_Forum]

--- Quote Start ---  Any other suggestions towards my code? How about the fact that the IOs are asynchronous input. I am not taking any precautions because they don't change 'that' often.  --- Quote End ---   I assumed that your input clock is derived from processor clock, in this case all bus signals are actually synchronous, you have to observe setup and hold times however.   If the bus signals are unrelated to clk, reliable operation can't be expected.  As I already mentioned, we simply have to assume, that the interface is cooperating correctly with coldfire bus signals. You have to check this.  P.S.: The latter is also my comment on your last question. The FSM as such has no race conditions, as far as I see. But this doesn't guarantee correct timing of bus signals. I don't know the respective requirements and can't suggest a solution.

[Altera_Forum]

The input clock is indeed drived from MCU and all the control signals (for read/write) from MCU is indeed synchronous with this clock. However, the point of this piece of code is to map some other external IOs from other devices (namely FEC chip, SerDes, XFP and external PLLs) to an address space so MCU can access/control the status of these external devices. For those input/output, most of them are asyn signals. Should I take precaution for them (use two DFFs at the first stage to synchronous them)? Or I can ignore them because they change so infrequently (and miss read them in one clock cycle simply doesn't matter) that in real operation, it doesn't matter that much? 

 Also, please explain why there's no race condition? For example, the FSM will change state on every rising edge of clock and also on the same rising edge of clock, FSM must produce output signals which depends on the CURRENT STATE. Wouldn't this changing of state be in a race condition with the output signals? If not, is it because Altera Quartus II is smart enough to detect such code style and avoide it by itself?   TIA      --- Quote Start ---  I assumed that your input clock is derived from processor clock, in this case all bus signals are actually synchronous, you have to observe setup and hold times however.    If the bus signals are unrelated to clk, reliable operation can't be expected.   As I already mentioned, we simply have to assume, that the interface is cooperating correctly with coldfire bus signals. You have to check this.   P.S.: The latter is also my comment on your last question. The FSM as such has no race conditions, as far as I see. But this doesn't guarantee correct timing of bus signals. I don't know the respective requirements and can't suggest a solution.  --- Quote End ---