[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[oc] Is OCIDEC (and other opencore-cores) ill-suited for FPGA's?
Having implemented the OCIDEC3 (IDE(ATA)-controller with PIO and DMA
support) for Xilinx SpartanII I get an huge block which eats up more
then 500 slices. This is a few times more than expected. Having a closer
look on it, there are 2 design details responsible for that.
1) Register for timings are not affected by counter widht.
Regardless the generic for the maximum counterwidth, the many
registers for the timings are fixed in counter width (8bit?). There are
a lot of wasted FF here. Even better area efficiency could be reached by
using Embedded SRAM cells as register bank.
2) Strange counter implementation.
This doesnt seem to have the same impact as the register width, but
it,s used in other opencore desings too. Is there a reason for the FF
consuming "row of runonce counters" architecture I'm not aware off?
Let me explain:
a)The Synthesis tool (exemplar for me) doesnt realize any counter
in this design and therefore any optimized counter macro are missed.
This is due the description used for the upDown counter here. Better
is something which uses "counter <= counter + 1;" or so, instead of
dealing of dealing with carry in and carry out.
b)Actually "run once" downcounters are used as basic elemenst for the
"run once" thing,the component up down counter is never used for
counting up. This is confusing.
Why not using a clearly written runonce counter as basic element?
c)For every duration to count a new counter is used. Why not restarting
the loadable counter or built "self loading counter?" All You needed
is one FSM, (most states switched by "counter reaches zero"), one muxer
(FSM states selects timings as load value for counter) and one
counter(started by FSM or after reaching zero). This saves gates in
FPGA. Perhaps OCIDEC was designed for ASIC's.
BTW: The VHDL code of ocidec has syntax errors. Seems to be an untested
ouput of a Verilog2VHDL converter.
Best regards
Volker Urban
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml