Complex timing diagram -> VHDL, ideas for approach?

I have a CMOS image sensor which has quite a large number of control signals which have specific timing constraints, most of which are hold times between certain sets of signals (I've attached 2 images which give you a sense). I'm using a Spartan 6 to generate the timing signals. My initial approach to this was to create a FSM which triggers counters to count to specific delays before the next state is reached, therefore the overall state is actually stored within both the encoded FSM state and the count value for each of the counters.

As you can imagine, with such a large number of signals, this approach creates some headaches. Furthermore, because some of the counters are running concurrently, and some of them require delays in the microsecond range and some in the nanosecond range, it is not easy to reuse counters in a way that is intuitive, so really it ends up being a FSM with way too many states for code readability in VHDL.

Is there another approach you would use to tackle this problem? I thought about storing the outputs into some ROM, and then advancing through in sequence, but it seems like there isn't a good resolution that would capture both nano and micro-second granularity. Either the ROM would be huge, or the timing would be too coarse. This seems like something that would be easy to do with a micro-controller that has a fast enough clock and IO , but oddly difficult to do on a FPGA (which is sort of surprising since this is the sort of thing I usually imagine FPGAs doing).

Finally, is there some tool that sort of generates VHDL given a timing diagram like this? In this case, all the signals are deterministic, it is only a matter of generating the state machine behind it. It seems like a common enough problem to have an industry standard way of doing it...

Thanks in advance for your advice

why bother with a FSM at all? if its all deterministic just have the counter run through the total time and have the signals toggle at their given on/off intervals?

TrickyDicky said:

why bother with a FSM at all? if its all deterministic just have the counter run through the total time and have the signals toggle at their given on/off intervals?

Click to expand...

That's a good point, I guess I can just have a ROM that has the first couple of bits be the "sequence time", and the rest of the bits be the outputs of the various signals. Now that you point that out, the only real clock is X_CLK (in the second diagram) for reading out each row, and that can be special cased with some additional logic. The rest of the signals only toggle once per line or once per frame.

There probably still needs to be a FSM because some of the diagram repeats for each row of the image and some for each frame, but it sounds like you are right in that it's a mistake to try to encode the position along the timing diagram into the state.

Thanks!

Not sure if this would help you, but one approach I've used is to use a 'one-shot' module which generates a pulse output. The inputs are a trigger, delay-time, and pulse-width, where the size of the delay-time and pulse-width inputs are generics so that one module fits all situations. Thus, it's very easy to establish the delay from one event to another.

Zuofu said:

That's a good point, I guess I can just have a ROM that has the first couple of bits be the "sequence time", and the rest of the bits be the outputs of the various signals. Now that you point that out, the only real clock is X_CLK (in the second diagram) for reading out each row, and that can be special cased with some additional logic. The rest of the signals only toggle once per line or once per frame.

There probably still needs to be a FSM because some of the diagram repeats for each row of the image and some for each frame, but it sounds like you are right in that it's a mistake to try to encode the position along the timing diagram into the state.

Thanks!

Click to expand...

Tricky isn't even suggesting a ROM just use a generic set/reset flop structure and a simple if (counter = SET_TIME) output_sig <= SET_VAULE; elsif (counter = RST_TIME) output_sig <= RST_VALUE; endif. The counter sequences over the entire period at the fastest clock rate you require.

All the SET_TIME...RST_TIME etc. generics/CONSTANTS can be grouped together so you can sort of see the timing in the numbers used.

for a small number of output signals and a short enough space of time, a rom would probably use fewer resources than a load of compares and stuff. But with a longer time period and more signals, memory requirements may get silly.

Thanks for the advice all, I'll try it with if statements on a single master counter.