Dual data rate in Xilinx WebPACK 7.1

[Mike Treseler]

Mike,

I've seen your template, and although I prefer not to split everything
out into separate procedures for init, update, and output, I really
like the concept of a single process, even/especially for combo
outputs.

Note that I use the template for
new rtl IP in level two entities.
I do use more than one entity in most designs.
Internal registers and combinational nodes (if any)
are all declared as variables.
All port outputs are registered.

However, if there are storage elements that you do not want/need to
reset (like clb rams that cannot be reset), leaving them out of the
"init" process/clause will result in a clock disable on reset (using
synplicity at least) for those elements, which is seldom wanted either.
Synplicity warns you when this happens, but it cannot be avoided in
your template. Note that the clock disable is required to generate
hardware that behaves like the RTL in such cases, since if the reset is
active, the clocked clause will not execute.

If I have to infer a vendor ram, I will
use the recommended template and, until now, had not
considered trying to make these things fit into one
of my structured entities.

I have found that, putting the init code at the end of the process, in
its own if-then clause, allows you to specify only those storage
elements that need reset, without the clock disable on those elements
left unreset.

Interesting. I'll have a look.
I ran into a similar problem when developing the templates,
whenever there was any mismatch in how an output variable
and it's associated output port is reset or updated.
This is one reason I settled on the v_rst template
that resets only variables and outputs only variables.
For an example of a clock enable/disables handled
inside the template, see the "if bit_done then"
clauses in the reference design.

For example:
process (reset, clock) is
...
begin
if rising_edge(clock) then
update; -- update internal variables (regs or combos)
end if;
if reset then
init; -- reset desired flops
end if;
output; -- assign output signals

\
Note that I don't declare or use any signals.
Output assignments are all "port gets variable"
out_port <= out_port_v;

end process;
Note that you don't get a friendly reminder during synthesis that you
dropped a register from your init clause, but at least it works without
the clock disable.

Andy Jones

Thanks for sharing the ideas!

-- Mike Treseler

 

[Andy]

Mike,

I usually find myself "stretching" the documented inferrence templates
to better fit my behavioral description. There are also some
interesting capabilities where optimizations can be made with
synchronous set/reset over what would be possible with their async
counterparts. Therefore, I find myself using a lot of registers that
don't have an async reset for one reason or another.

I see your point about not declaring any signals, and only having one
process per entity, and that your template updates the output ports
with signal assignments.

I occasionally have multiple synchronous processes in one entity,
depending on how loosely or tightly coupled the two tasks are. For me,
there is a gray area where two tasks are loosely coupled enough that I
prefer to constrain their interaction to a few signals, yet not so
unrelated as to warrant a separate entity altogether. Dual port, dual
clock block ram arrays are a good example of this; ram typically cannot
be inferred from an array that crosses an entity boundary since it is
difficult for the synthesis tool to verify single/dual port access when
that access is spread across entities. Although separate clocks can
sometimes be handled in one process, separating them confines the sync
boundary to signals instead of variables, and therefore makes the sync
boundary easier to audit.

Andy Jones

 

[Mike Treseler]

I usually find myself "stretching" the documented inferrence templates
to better fit my behavioral description. There are also some
interesting capabilities where optimizations can be made with
synchronous set/reset over what would be possible with their async
counterparts. Therefore, I find myself using a lot of registers that
don't have an async reset for one reason or another.

I use the asynch reset to give me a
single starting point for simulation.
Synchronous initialization is covered
by IDLE or INIT states which may occur
at any time.

I see your point about not declaring any signals, and only having one
process per entity, and that your template updates the output ports
with signal assignments.

Ports are the best kind of
signal because they have a direction.

I occasionally have multiple synchronous processes in one entity,
depending on how loosely or tightly coupled the two tasks are. For me,
there is a gray area where two tasks are loosely coupled enough that I
prefer to constrain their interaction to a few signals, yet not so
unrelated as to warrant a separate entity altogether.

When I allow a two process architecture,
I have to think structurally and procedurally
at the same time and I lose a lot of
my mental simulation capabilities.
The process outputs must not conflict,
but their signals are directionless and
and carry previous rather than present values.

This is a gray area, but I usually come
down on the side of partitioning the inputs
and outputs and splitting the entity in two.

Dual port, dual
clock block ram arrays are a good example of this; ram typically cannot
be inferred from an array that crosses an entity boundary since it is
difficult for the synthesis tool to verify single/dual port access when
that access is spread across entities.

I know what you mean.
I have a two process, single clock synch fifo like this:
___
ram_access : process (clk) is
...

fifo : process (clk, rst) is
variable pushed : boolean; -- pushed last time?
variable popped : boolean; -- popped last time?
variable full_v : std_ulogic; -- full flag
variable empty_v : std_ulogic; -- full flag
...
___

that I am working on combining. Thanks
for sharing your perspectives.

-- Mike Treseler