2 years ago
or just add the pointless, incorrectly working async reset that every frigg
in' text book and every training example shows.
I'm on a project where we have no strong guidance and one member of the tea
m is the type who *knows* how to work a project and so has zero interest in
considering what others are doing.
This design will power up very infrequently. When it does power up there i
s little to no need for the circuit to hit the ground running so to speak.
If your circuit takes a millisecond to wind through a homing sequence and
find it's ready state, it is of no consequence. So reset requirements are
as lax as can be. Each circuit simply needs to find it's way to its home s
tate and join the band rather than everyone starting at the same time... an
d a one, and a two and a three...
My thoughts are to have the configuration process serve as the only reset.
We are using a Gowin FPGA and I checked with support who said initializati
on will be picked up as the starting state from configuration. So make sur
e your circuits won't have a lock state and you are done. This may require
a bit of attention, but it
Some wish to focus intently on what happens when the async global reset sig
nal is released. The concern is that with slow routing some parts of the d
esign may not see the release of the reset until a clock cycle later than o
thers. In fact, I suppose it may take more than one clock cycle for the gl
obal reset signal to be seen as released in every FF on the chip.
My thinking is that with such minimal constraints on the start up of the ch
ip (many sections have a 5 millisecond clock enable) very little of the chi
p cares exactly when it is released. Rather than add local reset circuits
to manage each section of the design with an async reset, it just seems sim
pler to design the section to reset itself through homing.
Anyway, this is a much longer post than I intended. Any thoughts?
-- Rick C. - Get 1,000 miles of free Supercharging